Chronological Thread 

< Chronological >      < Thread >

---

Some of the links in the Doxygen generated documentation seem broken so I cannot run through everything, I haven't looked at the code directly and probably won't.

I don't think the namespace will be cluttered with utility classes if they are deemed necessary then they will exist, a namespace is there to avoid name collisions if you are not going to have name collisions then you don't need extra namespaces. I'm not sure why you mentioned that it is already implemented that way in your fork that statement is irrelevant.

Both those documents given are named as the unofficial working draft, is this important. It would be better to base your work on the official specification it would seem.

The manager class appears to be the only way to create a model so that implies it is very important and should be in the overview diagram. The fact that it isn't in the overview diagram doesn't seem fine with me. We shall have to wait and see what others think.

On 01/28/15 16:30, Randall Britten wrote:

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

---

• [[cellml-dev] ] Feedback on libCellML design document, Randall Britten, 01/28/2015
  • Re: [[cellml-dev] ] Feedback on libCellML design document, Hugh Sorby, 01/28/2015
    • Re: [[cellml-dev] ] Feedback on libCellML design document, Randall Britten, 01/28/2015
      • Re: [[cellml-dev] ] Feedback on libCellML design document, David Nickerson, 01/28/2015
      • Re: [[cellml-dev] ] Feedback on libCellML design document, Hugh Sorby, 01/28/2015
        • Re: [[cellml-dev] ] Feedback on libCellML design document, Randall Britten, 01/29/2015
  • Re: [[cellml-dev] ] Feedback on libCellML design document, David Nickerson, 01/28/2015
    • Re: [[cellml-dev] ] Feedback on libCellML design document, Randall Britten, 01/29/2015
      • Re: [[cellml-dev] ] Feedback on libCellML design document, David Nickerson, 01/29/2015
  • <Possible follow-up(s)>
  • Re: [[cellml-dev] ] Feedback on libCellML design document, Randall Britten, 01/28/2015

---

Archive powered by MHonArc 2.6.18.