Constructor and Description |
---|
Deletion()   |
Deletion(CompPkgNamespaces compns)   |
Deletion(Deletion source)   |
Deletion(long level)   |
Deletion(long level,
long version)   |
Deletion(long level,
long version,
long pkgVersion)   |
Modifier and Type | Method and Description |
---|---|
boolean |
acceptComp(SWIGTYPE_p_CompVisitor v)   |
SBase |
cloneObject()
Creates and returns a deep copy of this
SBase object. |
void |
delete()
Explicitly deletes the underlying native object.
|
String |
getElementName()
Returns the XML element name of this object.
|
int |
getTypeCode()
Returns the libSBML type code for this object.
|
int |
saveReferencedElement()   |
int |
unsetId()
Unsets the value of the 'id' attribute of this SBML object.
|
int |
unsetName()
Unsets the value of the 'name' attribute of this SBML object.
|
clearReferencedElement, createSBaseRef, getElementByMetaId, getElementBySId, getIdRef, getMetaIdRef, getNumReferents, getPortRef, getReferencedElement, getReferencedElementFrom, getSBaseRef, getUnitRef, isSetIdRef, isSetMetaIdRef, isSetPortRef, isSetSBaseRef, isSetUnitRef, performDeletion, removeFromParentAndDelete, renameSIdRefs, setIdRef, setMetaIdRef, setPortRef, setSBaseRef, setUnitRef, unsetIdRef, unsetMetaIdRef, unsetPortRef, unsetSBaseRef, unsetUnitRef
getPackageName, getPackageURI, getPackageVersion, getParentModel
addCVTerm, addCVTerm, appendAnnotation, appendAnnotation, appendNotes, appendNotes, disablePackage, enablePackage, equals, getAncestorOfType, getAncestorOfType, getAnnotation, getAnnotationString, getColumn, getCVTerm, getCVTerms, getLevel, getLine, getListOfAllElements, getListOfAllElementsFromPlugins, getMetaId, getModel, getModelHistory, getNamespaces, getNotes, getNotesString, getNumCVTerms, getNumPlugins, getParentSBMLObject, getPlugin, getPlugin, getResourceBiologicalQualifier, getResourceModelQualifier, getSBMLDocument, getSBOTerm, getSBOTermAsURL, getSBOTermID, getVersion, hashCode, hasValidLevelVersionNamespaceCombination, isPackageEnabled, isPackageURIEnabled, isSetAnnotation, isSetMetaId, isSetModelHistory, isSetNotes, isSetSBOTerm, matchesRequiredSBMLNamespacesForAddition, matchesSBMLNamespaces, removeTopLevelAnnotationElement, removeTopLevelAnnotationElement, renameMetaIdRefs, renameUnitSIdRefs, replaceTopLevelAnnotationElement, replaceTopLevelAnnotationElement, setAnnotation, setAnnotation, setMetaId, setModelHistory, setNamespaces, setNotes, setNotes, setNotes, setSBOTerm, setSBOTerm, toSBML, unsetAnnotation, unsetCVTerms, unsetMetaId, unsetModelHistory, unsetNotes, unsetSBOTerm
public Deletion() throws SBMLConstructorException
SBMLConstructorException
public Deletion(CompPkgNamespaces compns) throws SBMLConstructorException
SBMLConstructorException
public Deletion(Deletion source) throws SBMLConstructorException
SBMLConstructorException
public Deletion(long level) throws SBMLConstructorException
SBMLConstructorException
public Deletion(long level, long version) throws SBMLConstructorException
SBMLConstructorException
public Deletion(long level, long version, long pkgVersion) throws SBMLConstructorException
SBMLConstructorException
public boolean acceptComp(SWIGTYPE_p_CompVisitor v)
public SBase cloneObject()
SBase
object.
cloneObject
 in class SBaseRef
SBase
object.public void delete()
In general, application software will not need to call this method directly. The Java language binding for libSBML is implemented as a language wrapper that provides a Java interface to libSBML's underlying C++/C code. Some of the Java methods return objects that are linked to objects created not by Java code, but by C++ code. The Java objects wrapped around them will be deleted when the garbage collector invokes the corresponding C++ finalize()
methods for the objects. The finalize()
methods in turn call the Deletion.delete()
method on the libSBML object.
This method is exposed in case calling programs want to ensure that the underlying object is freed immediately, and not at some arbitrary time determined by the Java garbage collector. In normal usage, callers do not need to invoke Deletion.delete()
themselves.
public String getElementName()
This is overridden by subclasses to return a string appropriate to the
SBML component. For example, Model
defines it as returning
'model'
, CompartmentType
defines it as returning 'compartmentType'
,
and so on.
getElementName
 in class SBaseRef
public int getTypeCode()
This method may return the type code of this SBML object, or it may
return SBML_UNKNOWN
. This
is because subclasses of SBase
are not required to implement this
method to return a type code. This method is meant primarily for the
LibSBML C interface, in which class and subclass information is not
readily available.
getTypeCode
 in class SBaseRef
SBML_UNKNOWN
(the default).
Deletion.getElementName()
,
CompBase.getPackageName()
public int saveReferencedElement()
saveReferencedElement
 in class SBaseRef
public int unsetId()
Most (but not all) objects in SBML include two common attributes: 'id'
and 'name'. The identifier given by an object's 'id' attribute value
is used to identify the object within the SBML model definition.
Other objects can refer to the component using this identifier. The
data type of 'id' is always either Sid
or
UnitSId
, depending on the object in question. Both
data types are defined as follows:
letter .= 'a'..'z','A'..'Z' digit .= '0'..'9' idChar .= letter | digit | '_' SId .= ( letter | '_' ) idChar*
The equality of SId
and UnitSId
type values
in SBML is determined by an exact character sequence match i.e.,
comparisons of these identifiers must be performed in a case-sensitive
manner. This applies to all uses of SId
and
UnitSId
.
public int unsetName()
Most (but not all) objects in SBML include two common attributes: 'id'
and 'name'. In contrast to the 'id' attribute, the 'name' attribute is
optional and is not intended to be used for cross-referencing purposes
within a model. Its purpose instead is to provide a human-readable
label for the component. The data type of 'name' is the type
string
defined in XML Schema. SBML imposes no
restrictions as to the content of 'name' attributes beyond those
restrictions defined by the string
type in XML Schema.
The recommended practice for handling 'name' is as follows. If a software tool has the capability for displaying the content of 'name' attributes, it should display this content to the user as a component's label instead of the component's 'id'. If the user interface does not have this capability (e.g., because it cannot display or use special characters in symbol names), or if the 'name' attribute is missing on a given component, then the user interface should display the value of the 'id' attribute instead. (Script language interpreters are especially likely to display 'id' instead of 'name'.)
As a consequence of the above, authors of systems that automatically generate the values of 'id' attributes should be aware some systems may display the 'id''s to the user. Authors therefore may wish to take some care to have their software create 'id' values that are: (a) reasonably easy for humans to type and read and (b) likely to be meaningful, for example by making the 'id' attribute be an abbreviated form of the name attribute value.
An additional point worth mentioning is although there are restrictions on the uniqueness of 'id' values, there are no restrictions on the uniqueness of 'name' values in a model. This allows software applications leeway in assigning component identifiers.