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

Text archives Help


Re: [[cellml-dev] ] Feedback on libCellML design document


Chronological Thread 
  • From: Randall Britten <r.britten AT auckland.ac.nz>
  • To: cellml-tools-developers Mailing List <cellml-tools-developers AT lists.cellml.org>
  • Subject: Re: [[cellml-dev] ] Feedback on libCellML design document
  • Date: Wed, 28 Jan 2015 03:30:35 +0000
  • Accept-language: en-NZ, en-US
Hi Hugh

I’ve just posted the Doxygen, which will give you an idea of the current
state of the C++ code in my fork, so please look there too for more info on
the design, or look at the C++ code itself.

The benefit of having “model” and “general” is to avoid cluttering the model
namespace with utility classes etc. It’s already implemented that way in the
C++ code in my fork.

The getXML method is out of date, the latest design (as per above mentioned
Doxygen and C++ code) just has a “libcellml::general::createXml" method. As
you know, the design doc is not automatically updated as the C++ code is, so
treat the code as authoritative for any discrepancies like this. I’ll aim to
fix this soon.

Deriving all objects from a common base class might be a good idea, but none
of the implemented use cases so far show any real benefit to doing that yet,
but if that ever does appear to be beneficial then we should do it.

Boolean and Real are the two built-in types in the CellML 1.2 draft that I’ve
based this work on so far (copy available here:
http://codecurve.github.io/cellml-core-spec/, draft secondary spec here
http://codecurve.github.io/cellml-dae-events-secondary/).

Not sure what your point is regarding the manager class being required to
make a model object but not being mentioned in the overview, I agree that is
the case, and it seems fine to me.

I think Manager is needed to allow references between models for imports, but
you are right that no use cases expose this yet, nevertheless, it seems
pretty clear to me that it will work well for that.

Regards,
Randall



From: Hugh Sorby
<h.sorby AT auckland.ac.nz<mailto:h.sorby AT auckland.ac.nz>>
Reply-To:
"cellml-tools-developers AT lists.cellml.org<mailto:cellml-tools-developers AT lists.cellml.org>"

<cellml-tools-developers AT lists.cellml.org<mailto:cellml-tools-developers AT lists.cellml.org>>
Date: Wednesday, 28 January 2015 3:15 pm
To:
"cellml-tools-developers AT lists.cellml.org<mailto:cellml-tools-developers AT lists.cellml.org>"

<cellml-tools-developers AT lists.cellml.org<mailto:cellml-tools-developers AT lists.cellml.org>>
Subject: Re: [[cellml-dev] ] Feedback on libCellML design document


feedback

* I don't see the requirement to have embedded namespaces, one namespace
should be sufficient 'libcellml'
* model class should have method serialise/serialize and be passed a
serializer or makes use of a default serializer say 'xml', not a method
getXML()
* all objects should be derived from some base class with a name and/or
id member
* cannot see why booleancodomainvariable and realcodomainvariable classes
exist
* the overview of the object model makes no mention of the manager class
yet it seems it is required to create a model
* I cannot see the need for a manager class to create models, certainly
at the current stage of development where we are looking to satisfy the first
few use cases

Cheers,
Hugh.

On 01/28/15 10:49, Randall Britten wrote:
Hi

The latest version of the libCellML design document is available here:
https://github.com/codecurve/libcellml/blob/uml01/docs/source/design.rst

The design document does not completely match the design of the C++ code in
my fork, since our aim at the moment is to get community feedback on the
design, rather than to document the code.

Please send feedback, I’ll aim to reply within a day when applicable.

Regards,
Randall Britten


Archive powered by MHonArc 2.6.18.

Top of page