Chronological Thread 

< Chronological >      < Thread >

---

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::none when
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::optional from 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::optional itself 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>

---

• [[cellml-dev] ] libCellML - Optional values, Randall Britten, 04/01/2015
  • RE: [[cellml-dev] ] libCellML - Optional values, Richard Christie, 04/01/2015
    • Re: [[cellml-dev] ] libCellML - Optional values, David Brooks, 04/01/2015
      • Re: [[cellml-dev] ] libCellML - Optional values, Randall Britten, 04/01/2015
        • RE: [[cellml-dev] ] libCellML - Optional values, Richard Christie, 04/01/2015
          • Re: [[cellml-dev] ] libCellML - Optional values, Randall Britten, 04/01/2015
            • RE: [[cellml-dev] ] libCellML - Optional values, Richard Christie, 04/01/2015
              • Re: [[cellml-dev] ] libCellML - Optional values, Randall Britten, 04/01/2015
  • <Possible follow-up(s)>
  • Re: [[cellml-dev] ] libCellML - Optional values, Gary Mirams, 04/12/2015
    • Re: [[cellml-dev] ] libCellML - Optional values, Jonathan Cooper, 04/14/2015
      • RE: [[cellml-dev] ] libCellML - Optional values, Alan Garny, 04/14/2015

---

Archive powered by MHonArc 2.6.18.