A list for the developers of CellML tools

Text archives Help


Re: [[cellml-dev] ] libCellML - Optional values


Chronological Thread 
  • From: David Brooks <d.brooks AT auckland.ac.nz>
  • To: cellml-tools-developers AT lists.cellml.org, "cellml-tools-developers AT cellml.org" <cellml-tools-developers AT cellml.org>
  • Subject: Re: [[cellml-dev] ] libCellML - Optional values
  • Date: Wed, 01 Apr 2015 13:23:34 +1300

In general I agree with Richard's points. However a lot of Boost's functionality is provided at compile time (via its headers) and only a few modules depend on the use of a libraries. What is the case for boost::optional ??

In the specific example, if an empty string is not a valid value for a name then I would return the empty string when the name is missing.


Regards,
Dave


On 1/04/15 12:52 pm, Richard Christie wrote:

I’d be disinclined to have dependencies on other libraries in any public API unless they performed a critical part of the actual work, not a trivial feature such as this.

You have to deal with delivery of the additional libraries and headers and any future version issues. Also, your clients’ code is exposed to extra libraries they possibly didn’t want, different versions of boost etc. Finally, the client usage of the API is modified e.g. you can’t just use the return value where a string is required.

In this case I’d expect a more thorough analysis of the issue and benefits. You’ve only mentioned a string name attribute, can you list any others and for which classes? Is an empty string a valid name? Can you mock up client code variants for the possible alternatives?

Regards,

Richard

*From:*cellml-tools-developers-request AT lists.cellml.org [mailto:cellml-tools-developers-request AT lists.cellml.org] *On Behalf Of *Randall Britten
*Sent:* Wednesday, 1 April 2015 10:50 a.m.
*To:*
cellml-tools-developers AT cellml.org
*Subject:* [[cellml-dev] ] libCellML - Optional values

Hi all

A few months ago, I wrote code that got through the first few use cases. This highlighted the need to handle optional values. For example, if an XML file is loaded into memory, and say the model element was missing the name attribute, then the in-memory representation would return boost::nonewhen model.getName()was called. (Even though a model is not valid without a name attribute, libCellML will allow processing of models that are not valid, for example, when continuing the authoring of a partially complete model.) Using boost::optionalfrom the Boost library seems to be technically superior by far than other approaches, for example using pointers, or having additional methods, e.g. model.hasName().

David Nickerson has expressed that he prefers not to use Boost in the public API.

Boost is pretty standard, and certainly is a well-respected library. boost::optionalitself is fairly straightforward to use.

Other uses of boost may be esoteric, and I too would rather avoid those, but that does not mean we should reject the entire library outright, rather, we should just assess each use of Boost on a case-by-case basis during code review.

Please send us your feedback, we’d like to hear from the community.

Regards,

Randall Britten

______________________________________________

Bioengineering Software Development Specialist

Auckland Bioengineering Institute

University of Auckland

Auckland, New Zealand

www.abi.auckland.ac.nz <http://www.abi.auckland.ac.nz>





Archive powered by MHonArc 2.6.18.

Top of page