A list for the developers of CellML tools

Text archives Help


[cellml-dev] r2372 - CellML_DOM_API/trunk/VACSS/sources


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-dev] r2372 - CellML_DOM_API/trunk/VACSS/sources
  • Date: Thu, 26 Jun 2008 10:14:21 +1200

Alan Garny wrote:
> Looking at the first set of changes to
> CellML_DOM_API/VACSS/sources/VACSSImpl.cpp, I couldn't help but notice that
> the reserved units (e.g. steradian) were, once again, hard coded. Once again
> indeed, because they are also hard coded in
> pce/chrome/content/controls/modeltreeview.xml. Now, I know that those are
> two different projects (CellML DOM API and PCEnv), but the point I want to
> make is that this kind of coding is very error prone.
>
Hi Alan,

I'm not sure what you would propose as an alternative to hard-coding in
the units... the lists of units are defined in the CellML Specification,
and the code is written to validate against the CellML specification, so
it seems that in this case including lists of units in the code makes
the most sense. If we expected that the list might be going to change,
we could minimise how much we repeat ourselves by putting a list of
units wrapped in a macro call inside an include file, and use a
different macro each time we include it (along the lines of how Mozilla
handles lists of CSS properties, HTML / XUL elements and the like), but
this is also confusing, so there is a trade-off involved.

> As it happens, the reserved units are also hard coded in
> CellML_DOM_API/CUSES/sources/CUSESImpl.cpp (in CDACUSES::BuiltinUnit).
> Regarding that function (CDACUSES::BuiltinUnit), I really don't like those
> if...then...else statements. Though this code will probably never be touched
> again, I find that kind of coding to be very error prone too.
>
It is true that the search tree data-structure is hard-coded in that
case, and so adding new entries while keeping the decision tree balanced
would be a difficult task. That said, C++ doesn't really provide any way
to express that we want such code to be generated... we could include
code (in a scripting language) which generates the decision tree code in
a comment, or make the decision tree generated, but again, it is a
trade-off between complexity and how often we feel that the list of
units will change.

Best regards,
Andrew





Archive powered by MHonArc 2.6.18.

Top of page