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.