Changes to libSBML's SBase class

Overview

In SBML, all components such as Species, Parameters, Reactions, etc., are derived from an SBase abstract type. The class hierarchy within libSBML mimics this; with the exception (in libSBML versions 1–3) that the id and name attributes are stored as member variables on the SBase class. However, in the SBML language definition, these attributes are not actually part of the SBase component. The original implementation was motivated by a desire for parsimony and other reasons, but practical experience has lead to the realization that this architectural decision leads to problems.

Example of the issue

Consider the following code fragment:

  Constraint *c = new Constraint();
  c->setId("c");

This code works in libSBML up through version 3.3.x. It creates a constraint object and sets the id attribute. However, the id attribute does not exist on an SBML Constraint. The reason this works in libSBML is that the object class is derived from SBase, and thus inherits the setId() function.

Solution

Obviously, it is possible to reimplement the setId function to determine whether or not it is valid to set the id attribute for the object concerned. However, the existence of the id and name on the SBase class has implications for several other functions; e.g. reading and writing SBML.

Therefore, libSBML-4 removes the member variables storing id and name from the SBase class and instead locates these within individual SBML component classes, where appropriate. Thus the Constraint class does not have these variables.