1 using System;
2 using System.Runtime.InteropServices;
3 
4 //------------------------------------------------------------------------------
5 // <auto-generated />
6 //
7 // This file was automatically generated by SWIG (http://www.swig.org).
8 // Version 4.0.2
9 //
10 // Do not make changes to this file unless you know what you are doing--modify
11 // the SWIG interface file instead.
12 //------------------------------------------------------------------------------
13 
14 namespace libsbmlcs {
15 
16  using System;
17  using System.Runtime.InteropServices;
18 
19 /**
20  * @sbmlpackage{core}
21  *
22 @htmlinclude pkg-marker-core.html A <em>compartment type</em> in SBML Level&nbsp;2.
23  *
24  * SBML Level&nbsp;2 Versions&nbsp;2&ndash;4 provide the <em>compartment
25  * type</em> as a grouping construct that can be used to establish a
26  * relationship between multiple Compartment objects.  A CompartmentType
27  * object only has an identity, and this identity can only be used to
28  * indicate that particular Compartment objects in the model belong to this
29  * type.  This may be useful for conveying a modeling intention, such as
30  * when a model contains many similar compartments, either by their
31  * biological function or the reactions they carry.  Without a compartment
32  * type construct, it would be impossible within SBML itself to indicate
33  * that all of the compartments share an underlying conceptual relationship
34  * because each SBML compartment must be given a unique and separate
35  * identity.  A CompartmentType has no mathematical meaning in
36  * SBML---it has no effect on a model's mathematical interpretation.
37  * Simulators and other numerical analysis software may ignore
38  * CompartmentType definitions and references to them in a model.
39  *
40  * There is no mechanism in SBML Level 2 for representing hierarchies of
41  * compartment types.  One CompartmentType instance cannot be the subtype
42  * of another CompartmentType instance; SBML provides no means of defining
43  * such relationships.
44  *
45  * As with other major structures in SBML, CompartmentType has a mandatory
46  * attribute, 'id', used to give the compartment type an identifier.  The
47  * identifier must be a text %string conforming to the identifer syntax
48  * permitted in SBML.  CompartmentType also has an optional 'name'
49  * attribute, of type @c string.  The 'id' and 'name' must be used
50  * according to the guidelines described in the SBML specification (e.g.,
51  * Section 3.3 in the Level 2 Version 4 specification).
52  *
53  * CompartmentType was introduced in SBML Level 2 Version 2.  It is not
54  * available in SBML Level&nbsp;1 nor in Level&nbsp;3.
55  *
56  * @see Compartment
57  * @see ListOfCompartmentTypes
58  * @see SpeciesType
59  * @see ListOfSpeciesTypes
60  *
61  *
62  *
63  */
64 
65 public class CompartmentType : SBase {
66 	private HandleRef swigCPtr;
67 
CompartmentType(IntPtr cPtr, bool cMemoryOwn)68 	internal CompartmentType(IntPtr cPtr, bool cMemoryOwn) : base(libsbmlPINVOKE.CompartmentType_SWIGUpcast(cPtr), cMemoryOwn)
69 	{
70 		//super(libsbmlPINVOKE.CompartmentTypeUpcast(cPtr), cMemoryOwn);
71 		swigCPtr = new HandleRef(this, cPtr);
72 	}
73 
getCPtr(CompartmentType obj)74 	internal static HandleRef getCPtr(CompartmentType obj)
75 	{
76 		return (obj == null) ? new HandleRef(null, IntPtr.Zero) : obj.swigCPtr;
77 	}
78 
getCPtrAndDisown(CompartmentType obj)79 	internal static HandleRef getCPtrAndDisown (CompartmentType obj)
80 	{
81 		HandleRef ptr = new HandleRef(null, IntPtr.Zero);
82 
83 		if (obj != null)
84 		{
85 			ptr             = obj.swigCPtr;
86 			obj.swigCMemOwn = false;
87 		}
88 
89 		return ptr;
90 	}
91 
Dispose(bool disposing)92   protected override void Dispose(bool disposing) {
93     lock(this) {
94       if (swigCPtr.Handle != global::System.IntPtr.Zero) {
95         if (swigCMemOwn) {
96           swigCMemOwn = false;
97           libsbmlPINVOKE.delete_CompartmentType(swigCPtr);
98         }
99         swigCPtr = new global::System.Runtime.InteropServices.HandleRef(null, global::System.IntPtr.Zero);
100       }
101       base.Dispose(disposing);
102     }
103   }
104 
105 
106 /**
107    * Creates a new CompartmentType object using the given SBML @p level and
108    * @p version values.
109    *
110    * @param level a long integer, the SBML Level to assign to this
111    * CompartmentType.
112    *
113    * @param version a long integer, the SBML Version to assign to this
114    * CompartmentType.
115    *
116    *
117  * @throws SBMLConstructorException
118  * Thrown if the given @p level and @p version combination are invalid
119  * or if this object is incompatible with the given level and version.
120  *
121  *
122    *
123    *
124  * @note Attempting to add an object to an SBMLDocument having a different
125  * combination of SBML Level, Version and XML namespaces than the object
126  * itself will result in an error at the time a caller attempts to make the
127  * addition.  A parent object must have compatible Level, Version and XML
128  * namespaces.  (Strictly speaking, a parent may also have more XML
129  * namespaces than a child, but the reverse is not permitted.)  The
130  * restriction is necessary to ensure that an SBML model has a consistent
131  * overall structure.  This requires callers to manage their objects
132  * carefully, but the benefit is increased flexibility in how models can be
133  * created by permitting callers to create objects bottom-up if desired.  In
134  * situations where objects are not yet attached to parents (e.g.,
135  * SBMLDocument), knowledge of the intented SBML Level and Version help
136  * libSBML determine such things as whether it is valid to assign a
137  * particular value to an attribute.
138  *
139  *
140    */ public
CompartmentType(long level, long version)141  CompartmentType(long level, long version) : this(libsbmlPINVOKE.new_CompartmentType__SWIG_0(level, version), true) {
142     if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve();
143   }
144 
145 
146 /**
147    * Creates a new CompartmentType object using the given SBMLNamespaces
148    * object @p sbmlns.
149    *
150    *
151  *
152  * The SBMLNamespaces object encapsulates SBML Level/Version/namespaces
153  * information.  It is used to communicate the SBML Level, Version, and (in
154  * Level&nbsp;3) packages used in addition to SBML Level&nbsp;3 Core.  A
155  * common approach to using libSBML's SBMLNamespaces facilities is to create an
156  * SBMLNamespaces object somewhere in a program once, then hand that object
157  * as needed to object constructors that accept SBMLNamespaces as arguments.
158  *
159  *
160    *
161    * It is worth emphasizing that although this constructor does not take an
162    * identifier argument, in SBML Level&nbsp;2 and beyond, the 'id'
163    * (identifier) attribute of a CompartmentType object is required to have a
164    * value.  Thus, callers are cautioned to assign a value after calling this
165    * constructor.  Setting the identifier can be accomplished using the
166    * method setId(@if java String@endif).
167    *
168    * @param sbmlns an SBMLNamespaces object.
169    *
170    *
171  * @throws SBMLConstructorException
172  * Thrown if the given @p sbmlns is inconsistent or incompatible
173  * with this object.
174  *
175  *
176    *
177    *
178  * @note Attempting to add an object to an SBMLDocument having a different
179  * combination of SBML Level, Version and XML namespaces than the object
180  * itself will result in an error at the time a caller attempts to make the
181  * addition.  A parent object must have compatible Level, Version and XML
182  * namespaces.  (Strictly speaking, a parent may also have more XML
183  * namespaces than a child, but the reverse is not permitted.)  The
184  * restriction is necessary to ensure that an SBML model has a consistent
185  * overall structure.  This requires callers to manage their objects
186  * carefully, but the benefit is increased flexibility in how models can be
187  * created by permitting callers to create objects bottom-up if desired.  In
188  * situations where objects are not yet attached to parents (e.g.,
189  * SBMLDocument), knowledge of the intented SBML Level and Version help
190  * libSBML determine such things as whether it is valid to assign a
191  * particular value to an attribute.
192  *
193  *
194    */ public
CompartmentType(SBMLNamespaces sbmlns)195  CompartmentType(SBMLNamespaces sbmlns) : this(libsbmlPINVOKE.new_CompartmentType__SWIG_1(SBMLNamespaces.getCPtr(sbmlns)), true) {
196     if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve();
197   }
198 
199 
200 /**
201    * Copy constructor; creates a copy of this CompartmentType object.
202    *
203    * @param orig the object to copy.
204    */ public
CompartmentType(CompartmentType orig)205  CompartmentType(CompartmentType orig) : this(libsbmlPINVOKE.new_CompartmentType__SWIG_2(CompartmentType.getCPtr(orig)), true) {
206     if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve();
207   }
208 
209 
210 /**
211    * Creates and returns a deep copy of this CompartmentType object.
212    *
213    * @return the (deep) copy of this CompartmentType object.
214    */ public new
clone()215  CompartmentType clone() {
216     global::System.IntPtr cPtr = libsbmlPINVOKE.CompartmentType_clone(swigCPtr);
217     CompartmentType ret = (cPtr == global::System.IntPtr.Zero) ? null : new CompartmentType(cPtr, true);
218     return ret;
219   }
220 
221 
222 /**
223    * Returns the value of the 'id' attribute of this CompartmentType.
224    *
225    * @note Because of the inconsistent behavior of this function with
226    * respect to assignments and rules, it is now recommended to
227    * use the getIdAttribute() function instead.
228    *
229    *
230  *
231  * The identifier given by an object's 'id' attribute value
232  * is used to identify the object within the SBML model definition.
233  * Other objects can refer to the component using this identifier.  The
234  * data type of 'id' is always <code>SId</code> or a type derived
235  * from that, such as <code>UnitSId</code>, depending on the object in
236  * question.  All data types are defined as follows:
237  * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
238  *   letter ::= 'a'..'z','A'..'Z'
239  *   digit  ::= '0'..'9'
240  *   idChar ::= letter | digit | '_'
241  *   SId    ::= ( letter | '_' ) idChar*
242  * </pre>
243  * The characters <code>(</code> and <code>)</code> are used for grouping,
244  * the character <code>*</code> 'zero or more times', and the character
245  * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers
246  * is determined by an exact character sequence match; i.e., comparisons must
247  * be performed in a case-sensitive manner.  This applies to all uses of
248  * <code>SId</code>, <code>SIdRef</code>, and derived types.
249  *
250  * Users need to be aware of some important API issues that are the result of
251  * the history of SBML and libSBML.  Prior to SBML Level&nbsp;3
252  * Version&nbsp;2, SBML defined 'id' and 'name' attributes on only a subset
253  * of SBML objects.  To simplify the work of programmers, libSBML's API
254  * provided get, set, check, and unset on the SBase object class itself
255  * instead of on individual subobject classes. This made the
256  * get/set/etc. methods uniformly available on all objects in the libSBML
257  * API.  LibSBML simply returned empty strings or otherwise did not act when
258  * the methods were applied to SBML objects that were not defined by the SBML
259  * specification to have 'id' or 'name' attributes.  Additional complications
260  * arose with the rule and assignment objects: InitialAssignment,
261  * EventAssignment, AssignmentRule, and RateRule.  In early versions of SBML,
262  * the rule object hierarchy was different, and in addition, then as now,
263  * they possess different attributes: 'variable' (for the rules and event
264  * assignments), 'symbol' (for initial assignments), or neither (for
265  * algebraic rules).  Prior to SBML Level&nbsp;3 Version&nbsp;2, getId()
266  * would always return an empty string, and isSetId() would always return @c
267  * false for objects of these classes.
268  *
269  * With the addition of 'id' and 'name' attributes on SBase in Level&nbsp;3
270  * Version&nbsp;2, it became necessary to introduce a new way to interact
271  * with the attributes more consistently in libSBML to avoid breaking
272  * backward compatibility in the behavior of the original 'id' methods.  For
273  * this reason, libSBML provides four functions (getIdAttribute(),
274  * setIdAttribute(@if java String@endif), isSetIdAttribute(), and
275  * unsetIdAttribute()) that always act on the actual 'id' attribute inherited
276  * from SBase, regardless of the object's type.  <strong>These new methods
277  * should be used instead of the older getId()/setId()/etc. methods</strong>
278  * unless the old behavior is somehow necessary.  Regardless of the Level and
279  * Version of the SBML, these functions allow client applications to use more
280  * generalized code in some situations (for instance, when manipulating
281  * objects that are all known to have identifiers).  If the object in
282  * question does not posess an 'id' attribute according to the SBML
283  * specification for the Level and Version in use, libSBML will not allow the
284  * identifier to be set, nor will it read or write 'id' attributes for those
285  * objects.
286  *
287  *
288    *
289    * @return the id of this CompartmentType.
290    *
291    * @see getIdAttribute()
292    * @see setIdAttribute(string sid)
293    * @see isSetIdAttribute()
294    * @see unsetIdAttribute()
295    */ public new
getId()296  string getId() {
297     string ret = libsbmlPINVOKE.CompartmentType_getId(swigCPtr);
298     return ret;
299   }
300 
301 
302 /**
303    * Returns the value of the 'name' attribute of this CompartmentType object.
304    *
305    *
306  *
307  *
308  * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
309  * moved to SBase directly, instead of being defined individually for many
310  * (but not all) objects.  LibSBML has for a long time provided functions
311  * defined on SBase itself to get, set, and unset those attributes, which
312  * would fail or otherwise return empty strings if executed on any object
313  * for which those attributes were not defined.  Now that all SBase objects
314  * define those attributes, those functions now succeed for any object with
315  * the appropriate level and version.
316  *
317  * The 'name' attribute is
318  * optional and is not intended to be used for cross-referencing purposes
319  * within a model.  Its purpose instead is to provide a human-readable
320  * label for the component.  The data type of 'name' is the type
321  * <code>string</code> defined in XML Schema.  SBML imposes no
322  * restrictions as to the content of 'name' attributes beyond those
323  * restrictions defined by the <code>string</code> type in XML Schema.
324  *
325  * The recommended practice for handling 'name' is as follows.  If a
326  * software tool has the capability for displaying the content of 'name'
327  * attributes, it should display this content to the user as a
328  * component's label instead of the component's 'id'.  If the user
329  * interface does not have this capability (e.g., because it cannot
330  * display or use special characters in symbol names), or if the 'name'
331  * attribute is missing on a given component, then the user interface
332  * should display the value of the 'id' attribute instead.  (Script
333  * language interpreters are especially likely to display 'id' instead of
334  * 'name'.)
335  *
336  * As a consequence of the above, authors of systems that automatically
337  * generate the values of 'id' attributes should be aware some systems
338  * may display the 'id''s to the user.  Authors therefore may wish to
339  * take some care to have their software create 'id' values that are: (a)
340  * reasonably easy for humans to type and read; and (b) likely to be
341  * meaningful, for example by making the 'id' attribute be an abbreviated
342  * form of the name attribute value.
343  *
344  * An additional point worth mentioning is although there are
345  * restrictions on the uniqueness of 'id' values, there are no
346  * restrictions on the uniqueness of 'name' values in a model.  This
347  * allows software applications leeway in assigning component identifiers.
348  *
349  * Regardless of the level and version of the SBML, these functions allow
350  * client applications to use more generalized code in some situations
351  * (for instance, when manipulating objects that are all known to have
352  * names).  If the object in question does not posess a 'name' attribute
353  * according to the SBML specification for the Level and Version in use,
354  * libSBML will not allow the name to be set, nor will it read or
355  * write 'name' attributes for those objects.
356  *
357  *
358  *
359  * @return the name of this SBML object, or the empty string if not set or unsettable.
360  *
361  * @see getIdAttribute()
362  * @see isSetName()
363  * @see setName(string sid)
364  * @see unsetName()
365  *
366  *
367    */ public new
getName()368  string getName() {
369     string ret = libsbmlPINVOKE.CompartmentType_getName(swigCPtr);
370     return ret;
371   }
372 
373 
374 /**
375    * Predicate returning @c true if this CompartmentType object's 'id'
376    * attribute is set.
377    *
378    *
379  *
380  *
381  * The identifier given by an object's 'id' attribute value
382  * is used to identify the object within the SBML model definition.
383  * Other objects can refer to the component using this identifier.  The
384  * data type of 'id' is always <code>SId</code> or a type derived
385  * from that, such as <code>UnitSId</code>, depending on the object in
386  * question.  All data types are defined as follows:
387  * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
388  *   letter ::= 'a'..'z','A'..'Z'
389  *   digit  ::= '0'..'9'
390  *   idChar ::= letter | digit | '_'
391  *   SId    ::= ( letter | '_' ) idChar*
392  * </pre>
393  * The characters <code>(</code> and <code>)</code> are used for grouping,
394  * the character <code>*</code> 'zero or more times', and the character
395  * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers
396  * is determined by an exact character sequence match; i.e., comparisons must
397  * be performed in a case-sensitive manner.  This applies to all uses of
398  * <code>SId</code>, <code>SIdRef</code>, and derived types.
399  *
400  * Users need to be aware of some important API issues that are the result of
401  * the history of SBML and libSBML.  Prior to SBML Level&nbsp;3
402  * Version&nbsp;2, SBML defined 'id' and 'name' attributes on only a subset
403  * of SBML objects.  To simplify the work of programmers, libSBML's API
404  * provided get, set, check, and unset on the SBase object class itself
405  * instead of on individual subobject classes. This made the
406  * get/set/etc. methods uniformly available on all objects in the libSBML
407  * API.  LibSBML simply returned empty strings or otherwise did not act when
408  * the methods were applied to SBML objects that were not defined by the SBML
409  * specification to have 'id' or 'name' attributes.  Additional complications
410  * arose with the rule and assignment objects: InitialAssignment,
411  * EventAssignment, AssignmentRule, and RateRule.  In early versions of SBML,
412  * the rule object hierarchy was different, and in addition, then as now,
413  * they possess different attributes: 'variable' (for the rules and event
414  * assignments), 'symbol' (for initial assignments), or neither (for
415  * algebraic rules).  Prior to SBML Level&nbsp;3 Version&nbsp;2, getId()
416  * would always return an empty string, and isSetId() would always return @c
417  * false for objects of these classes.
418  *
419  * With the addition of 'id' and 'name' attributes on SBase in Level&nbsp;3
420  * Version&nbsp;2, it became necessary to introduce a new way to interact
421  * with the attributes more consistently in libSBML to avoid breaking
422  * backward compatibility in the behavior of the original 'id' methods.  For
423  * this reason, libSBML provides four functions (getIdAttribute(),
424  * setIdAttribute(@if java String@endif), isSetIdAttribute(), and
425  * unsetIdAttribute()) that always act on the actual 'id' attribute inherited
426  * from SBase, regardless of the object's type.  <strong>These new methods
427  * should be used instead of the older getId()/setId()/etc. methods</strong>
428  * unless the old behavior is somehow necessary.  Regardless of the Level and
429  * Version of the SBML, these functions allow client applications to use more
430  * generalized code in some situations (for instance, when manipulating
431  * objects that are all known to have identifiers).  If the object in
432  * question does not posess an 'id' attribute according to the SBML
433  * specification for the Level and Version in use, libSBML will not allow the
434  * identifier to be set, nor will it read or write 'id' attributes for those
435  * objects.
436  *
437  *
438  *
439  * @return @c true if the 'id' attribute of this SBML object is
440  * set, @c false otherwise.
441  *
442  * @note Because of the inconsistent behavior of this function with
443  * respect to assignments and rules, it is recommended that callers
444  * use isSetIdAttribute() instead.
445  *
446  * @see getIdAttribute()
447  * @see setIdAttribute(string sid)
448  * @see unsetIdAttribute()
449  * @see isSetIdAttribute()
450  *
451  *
452    */ public new
isSetId()453  bool isSetId() {
454     bool ret = libsbmlPINVOKE.CompartmentType_isSetId(swigCPtr);
455     return ret;
456   }
457 
458 
459 /**
460    * Predicate returning @c true if this CompartmentType object's 'name'
461    * attribute is set.
462    *
463    *
464  *
465  *
466  * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
467  * moved to SBase directly, instead of being defined individually for many
468  * (but not all) objects.  LibSBML has for a long time provided functions
469  * defined on SBase itself to get, set, and unset those attributes, which
470  * would fail or otherwise return empty strings if executed on any object
471  * for which those attributes were not defined.  Now that all SBase objects
472  * define those attributes, those functions now succeed for any object with
473  * the appropriate level and version.
474  *
475  * The 'name' attribute is
476  * optional and is not intended to be used for cross-referencing purposes
477  * within a model.  Its purpose instead is to provide a human-readable
478  * label for the component.  The data type of 'name' is the type
479  * <code>string</code> defined in XML Schema.  SBML imposes no
480  * restrictions as to the content of 'name' attributes beyond those
481  * restrictions defined by the <code>string</code> type in XML Schema.
482  *
483  * The recommended practice for handling 'name' is as follows.  If a
484  * software tool has the capability for displaying the content of 'name'
485  * attributes, it should display this content to the user as a
486  * component's label instead of the component's 'id'.  If the user
487  * interface does not have this capability (e.g., because it cannot
488  * display or use special characters in symbol names), or if the 'name'
489  * attribute is missing on a given component, then the user interface
490  * should display the value of the 'id' attribute instead.  (Script
491  * language interpreters are especially likely to display 'id' instead of
492  * 'name'.)
493  *
494  * As a consequence of the above, authors of systems that automatically
495  * generate the values of 'id' attributes should be aware some systems
496  * may display the 'id''s to the user.  Authors therefore may wish to
497  * take some care to have their software create 'id' values that are: (a)
498  * reasonably easy for humans to type and read; and (b) likely to be
499  * meaningful, for example by making the 'id' attribute be an abbreviated
500  * form of the name attribute value.
501  *
502  * An additional point worth mentioning is although there are
503  * restrictions on the uniqueness of 'id' values, there are no
504  * restrictions on the uniqueness of 'name' values in a model.  This
505  * allows software applications leeway in assigning component identifiers.
506  *
507  * Regardless of the level and version of the SBML, these functions allow
508  * client applications to use more generalized code in some situations
509  * (for instance, when manipulating objects that are all known to have
510  * names).  If the object in question does not posess a 'name' attribute
511  * according to the SBML specification for the Level and Version in use,
512  * libSBML will not allow the name to be set, nor will it read or
513  * write 'name' attributes for those objects.
514  *
515  *
516  *
517  * @return @c true if the 'name' attribute of this SBML object is
518  * set, @c false otherwise.
519  *
520  * @see getName()
521  * @see setName(string sid)
522  * @see unsetName()
523  *
524  *
525    */ public new
isSetName()526  bool isSetName() {
527     bool ret = libsbmlPINVOKE.CompartmentType_isSetName(swigCPtr);
528     return ret;
529   }
530 
531 
532 /**
533    * Sets the value of the 'id' attribute of this CompartmentType.
534    *
535    *
536  *
537  * The string @p sid is copied.
538  *
539  *
540  *
541  * The identifier given by an object's 'id' attribute value
542  * is used to identify the object within the SBML model definition.
543  * Other objects can refer to the component using this identifier.  The
544  * data type of 'id' is always <code>SId</code> or a type derived
545  * from that, such as <code>UnitSId</code>, depending on the object in
546  * question.  All data types are defined as follows:
547  * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
548  *   letter ::= 'a'..'z','A'..'Z'
549  *   digit  ::= '0'..'9'
550  *   idChar ::= letter | digit | '_'
551  *   SId    ::= ( letter | '_' ) idChar*
552  * </pre>
553  * The characters <code>(</code> and <code>)</code> are used for grouping,
554  * the character <code>*</code> 'zero or more times', and the character
555  * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers
556  * is determined by an exact character sequence match; i.e., comparisons must
557  * be performed in a case-sensitive manner.  This applies to all uses of
558  * <code>SId</code>, <code>SIdRef</code>, and derived types.
559  *
560  * Users need to be aware of some important API issues that are the result of
561  * the history of SBML and libSBML.  Prior to SBML Level&nbsp;3
562  * Version&nbsp;2, SBML defined 'id' and 'name' attributes on only a subset
563  * of SBML objects.  To simplify the work of programmers, libSBML's API
564  * provided get, set, check, and unset on the SBase object class itself
565  * instead of on individual subobject classes. This made the
566  * get/set/etc. methods uniformly available on all objects in the libSBML
567  * API.  LibSBML simply returned empty strings or otherwise did not act when
568  * the methods were applied to SBML objects that were not defined by the SBML
569  * specification to have 'id' or 'name' attributes.  Additional complications
570  * arose with the rule and assignment objects: InitialAssignment,
571  * EventAssignment, AssignmentRule, and RateRule.  In early versions of SBML,
572  * the rule object hierarchy was different, and in addition, then as now,
573  * they possess different attributes: 'variable' (for the rules and event
574  * assignments), 'symbol' (for initial assignments), or neither (for
575  * algebraic rules).  Prior to SBML Level&nbsp;3 Version&nbsp;2, getId()
576  * would always return an empty string, and isSetId() would always return @c
577  * false for objects of these classes.
578  *
579  * With the addition of 'id' and 'name' attributes on SBase in Level&nbsp;3
580  * Version&nbsp;2, it became necessary to introduce a new way to interact
581  * with the attributes more consistently in libSBML to avoid breaking
582  * backward compatibility in the behavior of the original 'id' methods.  For
583  * this reason, libSBML provides four functions (getIdAttribute(),
584  * setIdAttribute(@if java String@endif), isSetIdAttribute(), and
585  * unsetIdAttribute()) that always act on the actual 'id' attribute inherited
586  * from SBase, regardless of the object's type.  <strong>These new methods
587  * should be used instead of the older getId()/setId()/etc. methods</strong>
588  * unless the old behavior is somehow necessary.  Regardless of the Level and
589  * Version of the SBML, these functions allow client applications to use more
590  * generalized code in some situations (for instance, when manipulating
591  * objects that are all known to have identifiers).  If the object in
592  * question does not posess an 'id' attribute according to the SBML
593  * specification for the Level and Version in use, libSBML will not allow the
594  * identifier to be set, nor will it read or write 'id' attributes for those
595  * objects.
596  *
597  *
598  *
599  * @param sid the string to use as the identifier of this object.
600  *
601  *
602  * @return integer value indicating success/failure of the
603  * function.  @if clike The value is drawn from the
604  * enumeration #OperationReturnValues_t. @endif The possible values
605  * returned by this function are:
606  * @li @link libsbml#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS@endlink
607  * @li @link libsbml#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE@endlink
608  * @li @link libsbml#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE@endlink
609  *
610  * @see getIdAttribute()
611  * @see setIdAttribute(string sid)
612  * @see isSetIdAttribute()
613  * @see unsetIdAttribute()
614  *
615  *
616    */ public new
setId(string sid)617  int setId(string sid) {
618     int ret = libsbmlPINVOKE.CompartmentType_setId(swigCPtr, sid);
619     if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve();
620     return ret;
621   }
622 
623 
624 /**
625    * Sets the value of the 'name' attribute of this CompartmentType.
626    *
627    *
628  *
629  *
630  * The string in @p name is copied.
631  *
632  * @param name the new name for the SBML object.
633  *
634  *
635  * @return integer value indicating success/failure of the
636  * function.  @if clike The value is drawn from the
637  * enumeration #OperationReturnValues_t. @endif The possible values
638  * returned by this function are:
639  * @li @link libsbml#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS@endlink
640  * @li @link libsbml#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE@endlink
641  *
642  *
643    */ public new
setName(string name)644  int setName(string name) {
645     int ret = libsbmlPINVOKE.CompartmentType_setName(swigCPtr, name);
646     if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve();
647     return ret;
648   }
649 
650 
651 /**
652    * Unsets the value of the 'name' attribute of this CompartmentType object.
653    *
654    *
655  *
656  *
657  * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
658  * moved to SBase directly, instead of being defined individually for many
659  * (but not all) objects.  LibSBML has for a long time provided functions
660  * defined on SBase itself to get, set, and unset those attributes, which
661  * would fail or otherwise return empty strings if executed on any object
662  * for which those attributes were not defined.  Now that all SBase objects
663  * define those attributes, those functions now succeed for any object with
664  * the appropriate level and version.
665  *
666  * The 'name' attribute is
667  * optional and is not intended to be used for cross-referencing purposes
668  * within a model.  Its purpose instead is to provide a human-readable
669  * label for the component.  The data type of 'name' is the type
670  * <code>string</code> defined in XML Schema.  SBML imposes no
671  * restrictions as to the content of 'name' attributes beyond those
672  * restrictions defined by the <code>string</code> type in XML Schema.
673  *
674  * The recommended practice for handling 'name' is as follows.  If a
675  * software tool has the capability for displaying the content of 'name'
676  * attributes, it should display this content to the user as a
677  * component's label instead of the component's 'id'.  If the user
678  * interface does not have this capability (e.g., because it cannot
679  * display or use special characters in symbol names), or if the 'name'
680  * attribute is missing on a given component, then the user interface
681  * should display the value of the 'id' attribute instead.  (Script
682  * language interpreters are especially likely to display 'id' instead of
683  * 'name'.)
684  *
685  * As a consequence of the above, authors of systems that automatically
686  * generate the values of 'id' attributes should be aware some systems
687  * may display the 'id''s to the user.  Authors therefore may wish to
688  * take some care to have their software create 'id' values that are: (a)
689  * reasonably easy for humans to type and read; and (b) likely to be
690  * meaningful, for example by making the 'id' attribute be an abbreviated
691  * form of the name attribute value.
692  *
693  * An additional point worth mentioning is although there are
694  * restrictions on the uniqueness of 'id' values, there are no
695  * restrictions on the uniqueness of 'name' values in a model.  This
696  * allows software applications leeway in assigning component identifiers.
697  *
698  * Regardless of the level and version of the SBML, these functions allow
699  * client applications to use more generalized code in some situations
700  * (for instance, when manipulating objects that are all known to have
701  * names).  If the object in question does not posess a 'name' attribute
702  * according to the SBML specification for the Level and Version in use,
703  * libSBML will not allow the name to be set, nor will it read or
704  * write 'name' attributes for those objects.
705  *
706  *
707  *
708  *
709  * @return integer value indicating success/failure of the
710  * function.  @if clike The value is drawn from the
711  * enumeration #OperationReturnValues_t. @endif The possible values
712  * returned by this function are:
713  * @li @link libsbml#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS@endlink
714  * @li @link libsbml#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED@endlink
715  *
716  * @see getName()
717  * @see setName(string sid)
718  * @see isSetName()
719  *
720  *
721    */ public new
unsetName()722  int unsetName() {
723     int ret = libsbmlPINVOKE.CompartmentType_unsetName(swigCPtr);
724     return ret;
725   }
726 
727 
728 /**
729    * Returns the libSBML type code for this SBML object.
730    *
731    *
732  *
733  * LibSBML attaches an identifying code to every kind of SBML object.  These
734  * are integer constants known as <em>SBML type codes</em>.  The names of all
735  * the codes begin with the characters <code>SBML_</code>.
736  * @if clike The set of possible type codes for core elements is defined in
737  * the enumeration #SBMLTypeCode_t, and in addition, libSBML plug-ins for
738  * SBML Level&nbsp;3 packages define their own extra enumerations of type
739  * codes (e.g., #SBMLLayoutTypeCode_t for the Level&nbsp;3 Layout
740  * package).@endif@if java In the Java language interface for libSBML, the
741  * type codes are defined as static integer constants in the interface class
742  * {@link libsbmlConstants}.  @endif@if python In the Python language
743  * interface for libSBML, the type codes are defined as static integer
744  * constants in the interface class @link libsbml@endlink.@endif@if csharp In
745  * the C# language interface for libSBML, the type codes are defined as
746  * static integer constants in the interface class
747  * @link libsbmlcs.libsbml@endlink.@endif  Note that different Level&nbsp;3
748  * package plug-ins may use overlapping type codes; to identify the package
749  * to which a given object belongs, call the
750  * <code>@if conly SBase_getPackageName()
751  * @else SBase::getPackageName()
752  * @endif</code>
753  * method on the object.
754  *
755  * The exception to this is lists:  all SBML-style list elements have the type
756  * @link libsbml#SBML_LIST_OF SBML_LIST_OF@endlink, regardless of what package they
757  * are from.
758  *
759  *
760    *
761    * @return the SBML type code for this object:
762    * @link libsbml#SBML_COMPARTMENT_TYPE SBML_COMPARTMENT_TYPE@endlink (default).
763    *
764    *
765  * @warning <span class='warning'>The specific integer values of the possible
766  * type codes may be reused by different libSBML plug-ins for SBML Level&nbsp;3.
767  * packages,  To fully identify the correct code, <strong>it is necessary to
768  * invoke both getPackageName() and getTypeCode()</strong> (or
769  * ListOf::getItemTypeCode()).</span>
770  *
771  *
772    *
773    * @see getElementName()
774    * @see getPackageName()
775    */ public new
getTypeCode()776  int getTypeCode() {
777     int ret = libsbmlPINVOKE.CompartmentType_getTypeCode(swigCPtr);
778     return ret;
779   }
780 
781 
782 /**
783    * Returns the XML element name of this object
784    *
785    * For CompartmentType, the element name is always @c 'compartmentType'.
786    *
787    * @return the name of this element.
788    *
789    * @see getTypeCode()
790    * @see getPackageName()
791    */ public new
getElementName()792  string getElementName() {
793     string ret = libsbmlPINVOKE.CompartmentType_getElementName(swigCPtr);
794     return ret;
795   }
796 
797 
798 /**
799    * Predicate returning @c true if all the required attributes for this
800    * CompartmentType object have been set.
801    *
802    * The required attributes for a CompartmentType object are:
803    * @li 'id'
804    *
805    * @return @c true if the required attributes have been set, @c false
806    * otherwise.
807    */ public new
hasRequiredAttributes()808  bool hasRequiredAttributes() {
809     bool ret = libsbmlPINVOKE.CompartmentType_hasRequiredAttributes(swigCPtr);
810     return ret;
811   }
812 
813 }
814 
815 }
816