Chronological Thread 

< Chronological >      < Thread >

---

Hi All,

I don't know when/where it is most appropriate to comment on the mock-ups,
but I find them very useful. I couldn't see how to add comments on github...
is this prevented?

Some comments:

----
1.i

std::string serialisedModel = model.serialise(libcellml::CELLML_XML);

In general I usually go with having an additional object describe what is
being serialised. That way you could add additional options as needed without
changing the API, and also have XML as a default. Other possible options:
indenting, line spacing, additional comments, RDF in or out.

Should this method be serialiseToString, to allow serialiseToFile. What about
a stream object?

You need to make a library-wide call on the UK/US language question:
serialise or serialize? FYI we use 'write' in Zinc which has no language
differences, but otherwise we us UK/NZ e.g. colour not color. BTW Hugh uses
serialize in the UML.

That said, there's nothing wrong with the odd convenience function for very
common tasks, and the convenience function could be added first with the
general function later.

Re: enumeration libcellml::CELLML_XML
For Zinc we made the call to prefix all enumerated values with the typename,
so the above could be (not sure if CellML is redundant), which you may
consider:
libcellml::CELLML_SERIALISATION_FORMAT_XML
namespace libcellml {
enum CellML_serialisation_format
CELLML_SERIALISATION_FORMAT_XML = 1
};
}

----
1.iii.cpp

I guess the argument for making the API permissive with invalid values such
as illegal names is that you may read it from XML, and a nice editor might
underline the bad names (like Visual Studio underlining code that won't
compile) for the user to fix. It might be difficult to write that nice editor
if you can't put the invalid values in the libcellml objects themselves;
you'd need to have a bunch of auxiliary data structures attached to the
libcellml data, and it couldn't be deserialised at all?

----
1.iv.a.cpp

libcellml::Component component;
model.addComponent(component);
component.setName("component_name");

If the first line constructs a new component and the second adds it to a
model, then you'd need a different class to store a reference to an existing
component (e.g. component = model.getComponent(name);). This case also has
components that are not owned by any model, which wouldn't be my preference;
can you re-parent components?
Alternatively, if the first line declares an empty handle to a component, the
second line is a fairly opaque way to construct it; I prefer a constructed
object to be returned by a method or constructor.

I'd prefer to always work through a handle to an object, and be explicit when
a new underlying object is created:

libcellml::Component component = model.createComponent();
component.setName("component_name");

If you want to allow components to exist outside of a model (why would you?),
you could use a static create method:

auto component = libcellml::Component::create();
model.addComponent(component);
component.setName("component_name");


----

Also a nit about the object model class diagrams. The inheritance arrow
should point to the base class since it means 'is a'. Also, the diamonds are
at the wrong end (it says a lot about UML that I had to look up the last
bit), but this fits with the verb 'has a'.
http://en.wikipedia.org/wiki/Class_diagram
I'd find these more useful if they were filled up with some key members and
methods.

cheers,
Richard


-----Original Message-----
From:
cellml-tools-developers-request AT lists.cellml.org

[mailto:cellml-tools-developers-request AT lists.cellml.org]
On Behalf Of David Nickerson
Sent: Monday, 27 April 2015 2:12 a.m.
To:
cellml-tools-developers AT lists.cellml.org
Subject: Re: [[cellml-dev] ] Object Model for libCellML

Thanks for the feedback Mike. The current plan is to simply fill in the
object model as implementation to support the use cases progresses, but the
general outline of the object model will be similar to those earlier
discussions. For example, I would imagine there is no group object per se in
the API, but rather a the ability to define a hierarchical nesting of
component objects. Similarly, connection objects would be dropped in favour
of relationships between variable objects. Imported units and components are
still components and units - instantiation of imports is something that will
likely be handled quite separately.

Another avenue for feedback is to mock up code that demonstrates various use
cases. I have started some at https://github.com/libcellml/use-case-mockups
based on the use cases we have so far
(https://github.com/cellml/libcellml/blob/develop/docs/usecases.rst),
but everyone should feel free to contribute such mock-ups - or even better,
actual tests! ;-)

As for math, its still a bit unknown - but bear in mind that libCellML is
designed, at least initially, to be a minimal implementation to create and
validate CellML models along with serialisation to and deserialisation from
CellML XML documents. Complete validation will require, for example, units
consistency within mathematical expressions - but perhaps not the level of
functionality you are thinking. Perhaps those are some common utility type
methods that sit at a higher level than libCellML itself.


Cheers,
Andre.

On Thu, Apr 23, 2015 at 1:02 AM, Mike Cooling
<mtcooling.research AT gmail.com>
wrote:
> Hi
>
> ...and Maths...
>
> How would someone decide how many equations were in there?
> How would someone decide what variables were in those equations?
> [aggregation relationship? only composition and gen/spec was shown] Or
> access structures to do things like quickly replace all instances of
> one variable with another?
>
> etc
>
> Mike
>
>
>
>
> On Thu, Apr 23, 2015 at 10:36 AM, Mike Cooling
> <mtcooling.research AT gmail.com>
> wrote:
>>
>> Hi
>>
>> With just a quick look (like 30 seconds):
>>
>> So obviously there is a lot not shown, most properties and
>> association relationships, but I as a new reader am left wondering
>> how you are planning to deal with:
>>
>> groups [assuming they will still exist] (hierarchical relationships
>> between components?) connections (some kind of collection property of
>> variables, maybe?) imported components and units ( tuples / source
>> property on components and units, maybe?)
>>
>>
>> Other than that the basic structure seems OK to me
>>
>> Cheerio
>>
>>
>>
>>
>>
>> On Wed, Apr 22, 2015 at 8:36 PM, Hugh Sorby
>> <h.sorby AT auckland.ac.nz>
>> wrote:
>>>
>>>
>>> Hi All,
>>>
>>> I have put together a starting point for the object model that I am
>>> proposing to use for libCellML. It is available at:
>>>
>>> https://github.com/hsorby/libcellml/blob/develop/docs/object_model.r
>>> st
>>>
>>> I would appreciate your opinion, as it is just starting out if
>>> something is not clear and requires further context just let me know and
>>> I'll add it.
>>>
>>> You can also leave comments on the GitHub pull request that this
>>> object model document belongs to here:
>>>
>>> https://github.com/cellml/libcellml/pull/10
>>>
>>> Cheers,
>>> Hugh.
>>>
>>> If you were wondering.
>>> - Yes this is a different model to the one proposed a few months ago.
>>> - Yes I didn't like the original proposal.
>>> - Yes we have had a staffing change.
>>> - Yes we no longer have a full-time developer working on this
>>> project (libCellML).
>>>
>>
>



--


David Nickerson
about.me/david.nickerson

---

• [[cellml-dev] ] Object Model for libCellML, Hugh Sorby, 04/22/2015
  • Re: [[cellml-dev] ] Object Model for libCellML, Mike Cooling, 04/23/2015
    • Re: [[cellml-dev] ] Object Model for libCellML, Mike Cooling, 04/23/2015
      • Re: [[cellml-dev] ] Object Model for libCellML, David Nickerson, 04/27/2015
        • RE: [[cellml-dev] ] Object Model for libCellML, Richard Christie, 04/28/2015
          • Re: [[cellml-dev] ] Object Model for libCellML, David Nickerson, 04/28/2015
      • Re: [[cellml-dev] ] Object Model for libCellML, Hugh Sorby, 04/29/2015
  • RE: [[cellml-dev] ] Object Model for libCellML, Koray Atalag, 04/26/2015
    • Re: [[cellml-dev] ] Object Model for libCellML, David Nickerson, 04/27/2015

---

Archive powered by MHonArc 2.6.18.