First login?
Lost password?
 
 
cellml-tools-developers AT lists.cellml.org 
A list for the developers of CellML tools

Text archives Help


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


Chronological Thread 
  • From: alan.garny at dpag.ox.ac.uk (Alan Garny)
  • Subject: [cellml-dev] r2372 - CellML_DOM_API/trunk/VACSS/sources
  • Date: Fri, 27 Jun 2008 16:34:05 +0100
> developers-bounces at cellml.org] On Behalf Of Andrew Miller
> 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.

I don't know enough about those technologies to suggest an alternative
solution.

All I wanted to do was to raise my concerns about 'copying/pasting' code in
general.

> > 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.

Current solution = ugly and error prone.

Alan



Archive powered by MHonArc 2.6.18.

Top of page