CompExtension.h File Reference

Definition of CompExtension_t, the core module of comp package. More...

Include dependency graph for CompExtension.h:

This graph shows which files directly or indirectly include this file:

Enumerations
enum	SBMLCompTypeCode_t {   SBML_COMP_SUBMODEL = 250,   SBML_COMP_MODELDEFINITION = 251,   SBML_COMP_EXTERNALMODELDEFINITION = 252,   SBML_COMP_SBASEREF = 253,   SBML_COMP_DELETION = 254,   SBML_COMP_REPLACEDELEMENT = 255,   SBML_COMP_REPLACEDBY = 256,   SBML_COMP_PORT = 257 }
	SBMLCompTypeCode_t Enumeration of possible types in the libSBML “comp” package implementation. More...

Detailed Description

Definition of CompExtension_t, the core module of comp package.

Author

Lucian Smith

Enumeration Type Documentation

enum SBMLCompTypeCode_t

SBMLCompTypeCode_t Enumeration of possible types in the libSBML “comp” package implementation.

LibSBML attaches an identifying code to every kind of SBML object. These are integer constants known as SBML type codes. The names of all the codes begin with the characters SBML_. The set of possible type codes for core elements is defined in the enumeration SBMLTypeCode_t, and in addition, libSBML plug-ins for SBML Level 3 packages define their own extra enumerations of type codes (e.g., SBMLLayoutTypeCode_t for the Level 3 Layout_t package). Note that different Level 3 package plug-ins may use overlapping type codes; to identify the package to which a given object belongs, call the SBase_getPackageName() method on the object.

The exception to this is lists: all SBML-style list elements have the type SBML_LIST_OF, regardless of what package they are from.

Here follow some additional general information about libSBML type codes:

• The codes are the possible return values (integers) for the following functions:
  • SBase_t::getTypeCode()
  • ListOf_t::getItemTypeCode()
  (Compatibility note: in libSBML 5, the type of return values of these functions changed from an enumeration to an integer for extensibility in the face of different programming languages.)

• Each package extension must define similar sets of values for each SBase_t subclass (e.g. SBMLLayoutTypeCode_t for the SBML Level 3 Layout extension, SBMLFbcTypeCode_t for the SBML Level 3 Flux Balance Constraints extension, etc.).

• The value of each package-specific type code can be duplicated between those of different packages. (This is necessary because the development of libSBML extensions for different SBML packages may be undertaken by different developers at different times; requiring the developers to coordinate their use of type codes would be nettlesome and probably doomed to failure.)

• To distinguish between the type codes of different packages, both the return value of SBase_t::getTypeCode() and SBase_t::getPackageName() must be checked. This is particularly important for functions that take an SBML type code as an argument, such as SBase_t::getAncestorOfType(), which by default assumes you are handing it a core type, and will return NULL if the value you give it is actually from a package.

The following example code illustrates the combined use of SBase_t::getPackageName() and SBase_t::getTypeCode():

Enumerator
SBML_COMP_SUBMODEL	Submodel
SBML_COMP_MODELDEFINITION	ModelDefinition
SBML_COMP_EXTERNALMODELDEFINITION	ExternalModelDefinition
SBML_COMP_SBASEREF	SBaseRef
SBML_COMP_DELETION	Deletion
SBML_COMP_REPLACEDELEMENT	ReplacedElement
SBML_COMP_REPLACEDBY	ReplacedBy
SBML_COMP_PORT	Port