Chronological Thread 

< Chronological >      < Thread >

---

On 12/06/13 11:49, David Nickerson wrote:
> Hi Andrew,
>
> That looks like a sensible approach to me, and fits within the current
> style and implementation of the API. Is there a reason for using
> 'makeFlattener()'? It would seem more consistent with the other
> services to use 'createFlattener()'.

Hi Andre,

I agree that it should be called createFlattener.

>
> I'm also wondering if perhaps we could use this service to start using
> more meaningful names for things and rather than MoFS simply use
> ModelFlatteningService in full?

Recently, when talking about the API in presentations, papers, posters,
and other documentation, I think most ABI people (including me) have
been trying to use the full names to refer to the services. However, in
code (for example, in file names and perhaps namespaces) it gets a bit
unwieldy to not have an abbreviation at all, especially for services
that have longer names; we would either have to come up with a shorter
names that don't convey what the service does as well, or be incredibly
verbose.

For example, do we really want to have to type things like the following?

#include "IfaceCellMLUnitsSimplificationAndExpansionService.hxx"
#include "CellMLUnitsSimplificationAndExpansionServiceBootstrap.hpp"
ObjRef<iface::cellml_units_simplification_and_expansion_service::CellMLUnitsSimplificationAndExpansionServiceBootstrap>

myCellMLUnitsSimplificationAndExpansionServiceBootstrap(CreateCellMLUnitsSimplificationAndExpansionServiceBootstrap());

I think it probably would get very tedious, and we might even start to
hit maximum identifier lengths in some of the languages we have bindings
for.

We could write the documentation for the files like this: "The Model
Flattening Service (MoFS) allows ..." to make it clear that Model
Flattening Service is the official name, and MoFS is only the
abbreviation used.

>
> While I am not sure if we should follow suit, it might be worth
> looking at the libSBML approach of having a generic converter which is
> implemented in several task specific interfaces
> (http://sbml.org/Software/libSBML/docs/cpp-api/class_s_b_m_l_converter.html).
> This would have the benefit of flexibility in regard to arbitrary
> conversions, such as decomposing 1.0 models into 1.1 or converting 1.1
> models into 1.2 models. Model flattening is then just another
> conversion task.

It looks like their conversion options have a string key
(http://sbml.org/Software/libSBML/docs/cpp-api/class_conversion_properties.html)

rather than being native attributes with typesafe getters and setters,
to allow the interface to be generic.

This is definitely suboptimal, and it makes me wonder whether the
benefits of having a generic converter interface outweigh the disadvantages

Best wishes,
Andrew

---

• [cellml-dev] A standard model flattening API?, Andrew Miller, 06/12/2013
  • [cellml-dev] A standard model flattening API?, David Nickerson, 06/12/2013
    • [cellml-dev] A standard model flattening API?, Andrew Miller, 06/12/2013

---

Archive powered by MHonArc 2.6.18.