001/* ----------------------------------------------------------------------------
002 * This file was automatically generated by SWIG (http://www.swig.org).
003 * Version 3.0.10
004 *
005 * Do not make changes to this file unless you know what you are doing--modify
006 * the SWIG interface file instead.
007 * ----------------------------------------------------------------------------- */
008
009package org.sbml.libsbml;
010
011/** 
012 * <span class="pkg-marker pkg-color-fbc"><a href="group__fbc.html">fbc</a></span>
013 Max or min value for a reaction flux.
014 <p>
015 * The {@link FluxBound} class of objects is used in Version&nbsp;1 of the SBML
016 * Level&nbsp;3 <a href='../../../extensions-summary.html#fbc'>Flux Balance Constraints</a> (&ldquo;fbc&rdquo;) package to express a single
017 * (in)equality that provides the maximum or minimum value that a reaction
018 * flux can obtain at steady state.  (This same information is encoded
019 * differently in Version&nbsp;2 of &ldquo;fbc&rdquo;; see the
020 * 'upperFluxBound' and 'lowerFluxBound' attributes on {@link FbcReactionPlugin}.)
021 <p>
022 * <h2>Attributes on {@link FluxBound}</h2>
023 <p>
024 * In addition to the common optional attributes 'id' and 'name', {@link FluxBound}
025 * takes three required attributes: 'reaction', 'operation' and 'value'.
026 * These three attributes define the meaning of the {@link FluxBound}, and are
027 * interpreted using the following expression:
028 * <center>
029 * <em>reaction</em>&nbsp;&nbsp;&nbsp;<em>operator</em>&nbsp;&nbsp;&nbsp;<em>value</em>
030 * </center>
031 <p>
032 * The 'reaction' attribute takes a value of <code>SIdRef</code>.  The value
033 * must be the identifier of a {@link Reaction} object defined within the enclosing
034 * model.
035 <p>
036 * The 'operation' attribute takes a value from an enumeration
037 * (#FluxBoundOperation_t) of Boolean operations that represent mathemetical
038 * inequalities.  Possible values for 'operation' include
039 * <code>'greaterEqual'</code>, <code>'equal'</code>, and others.
040 <p>
041 * The 'value' attribute takes a numerical value of type <code>double</code>,
042 * and represents the value of the flux bound.  The permitted values include
043 * positive infinity (<code>'INF'</code>) and negative infinity
044 * (<code>'-INF'</code>).
045 <p>
046 * The following is an example of a set of flux bounds encoded in this form; it
047 * also demonstrates the use of {@link ListOfFluxBounds}.
048 <p>
049 * <pre class='fragment'>
050&lt;fbc:listOfFluxBounds&gt;
051    &lt;fbc:fluxBound fbc:id='R1b' fbc:reaction='R1' fbc:operation='greaterEqual' fbc:value='1.2'/&gt;
052    &lt;fbc:fluxBound fbc:id='R2b' fbc:reaction='R2' fbc:operation='lessEqual' fbc:value='-1.2'/&gt;
053    &lt;fbc:fluxBound fbc:id='R3b' fbc:reaction='R3' fbc:operation='greaterEqual' fbc:value='-INF'/&gt;
054    &lt;fbc:fluxBound fbc:id='R4b' fbc:reaction='R4' fbc:operation='lessEqual' fbc:value='INF'/&gt;
055    &lt;fbc:fluxBound fbc:id='R5b' fbc:reaction='R5' fbc:operation='equal' fbc:value='1'/&gt;
056&lt;/fbc:listOfFluxBounds&gt;
057</pre>
058 <p>
059 * @note This class is only defined for Version&nbsp;1 of the
060 * &ldquo;fbc&rdquo; package specification.  It was replaced in
061 * Version&nbsp;2 by a {@link Parameter} referenced by the 'upperFluxBound' or
062 * 'lowerFluxBound' attributes on an {@link FbcReactionPlugin}.  {@link FluxBound} is
063 * therefore not used for Version&nbsp;2 &ldquo;fbc&rdquo; models.
064 <p>
065 * @see ListOfFluxBounds
066 */
067
068public class FluxBound extends SBase {
069   private long swigCPtr;
070
071   protected FluxBound(long cPtr, boolean cMemoryOwn)
072   {
073     super(libsbmlJNI.FluxBound_SWIGUpcast(cPtr), cMemoryOwn);
074     swigCPtr = cPtr;
075   }
076
077   protected static long getCPtr(FluxBound obj)
078   {
079     return (obj == null) ? 0 : obj.swigCPtr;
080   }
081
082   protected static long getCPtrAndDisown (FluxBound obj)
083   {
084     long ptr = 0;
085
086     if (obj != null)
087     {
088       ptr             = obj.swigCPtr;
089       obj.swigCMemOwn = false;
090     }
091
092     return ptr;
093   }
094
095  protected void finalize() {
096    delete();
097  }
098
099  public synchronized void delete() {
100    if (swigCPtr != 0) {
101      if (swigCMemOwn) {
102        swigCMemOwn = false;
103        libsbmlJNI.delete_FluxBound(swigCPtr);
104      }
105      swigCPtr = 0;
106    }
107    super.delete();
108  }
109
110  
111/**
112   * Creates a new {@link FbcAssociation} with the given SBML Level, Version, and
113   * &ldquo;fbc&rdquo;package version.
114   <p>
115   * @param level a long integer, the SBML Level to assign to this
116   * {@link FluxObjective}.
117   <p>
118   * @param version a long integer, the SBML Version to assign to this
119   * {@link FluxObjective}.
120   <p>
121   * @param pkgVersion a long integer, the SBML Fbc Version to assign to
122   * this {@link FluxObjective}.
123   <p>
124   * <p>
125 * @note Attempting to add an object to an {@link SBMLDocument} having a different
126 * combination of SBML Level, Version and XML namespaces than the object
127 * itself will result in an error at the time a caller attempts to make the
128 * addition.  A parent object must have compatible Level, Version and XML
129 * namespaces.  (Strictly speaking, a parent may also have more XML
130 * namespaces than a child, but the reverse is not permitted.)  The
131 * restriction is necessary to ensure that an SBML model has a consistent
132 * overall structure.  This requires callers to manage their objects
133 * carefully, but the benefit is increased flexibility in how models can be
134 * created by permitting callers to create objects bottom-up if desired.  In
135 * situations where objects are not yet attached to parents (e.g.,
136 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
137 * libSBML determine such things as whether it is valid to assign a
138 * particular value to an attribute.  For packages, this means that the 
139 * parent object to which this package element is being added must have
140 * been created with the package namespace, or that the package namespace
141 * was added to it, even if that parent is not a package object itself.
142   */ public
143 FluxBound(long level, long version, long pkgVersion) throws org.sbml.libsbml.SBMLConstructorException {
144    this(libsbmlJNI.new_FluxBound__SWIG_0(level, version, pkgVersion), true);
145  }
146
147  
148/**
149   * Creates a new {@link FbcAssociation} with the given SBML Level, Version, and
150   * &ldquo;fbc&rdquo;package version.
151   <p>
152   * @param level a long integer, the SBML Level to assign to this
153   * {@link FluxObjective}.
154   <p>
155   * @param version a long integer, the SBML Version to assign to this
156   * {@link FluxObjective}.
157   <p>
158   * @param pkgVersion a long integer, the SBML Fbc Version to assign to
159   * this {@link FluxObjective}.
160   <p>
161   * <p>
162 * @note Attempting to add an object to an {@link SBMLDocument} having a different
163 * combination of SBML Level, Version and XML namespaces than the object
164 * itself will result in an error at the time a caller attempts to make the
165 * addition.  A parent object must have compatible Level, Version and XML
166 * namespaces.  (Strictly speaking, a parent may also have more XML
167 * namespaces than a child, but the reverse is not permitted.)  The
168 * restriction is necessary to ensure that an SBML model has a consistent
169 * overall structure.  This requires callers to manage their objects
170 * carefully, but the benefit is increased flexibility in how models can be
171 * created by permitting callers to create objects bottom-up if desired.  In
172 * situations where objects are not yet attached to parents (e.g.,
173 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
174 * libSBML determine such things as whether it is valid to assign a
175 * particular value to an attribute.  For packages, this means that the 
176 * parent object to which this package element is being added must have
177 * been created with the package namespace, or that the package namespace
178 * was added to it, even if that parent is not a package object itself.
179   */ public
180 FluxBound(long level, long version) throws org.sbml.libsbml.SBMLConstructorException {
181    this(libsbmlJNI.new_FluxBound__SWIG_1(level, version), true);
182  }
183
184  
185/**
186   * Creates a new {@link FbcAssociation} with the given SBML Level, Version, and
187   * &ldquo;fbc&rdquo;package version.
188   <p>
189   * @param level a long integer, the SBML Level to assign to this
190   * {@link FluxObjective}.
191   <p>
192   * @param version a long integer, the SBML Version to assign to this
193   * {@link FluxObjective}.
194   <p>
195   * @param pkgVersion a long integer, the SBML Fbc Version to assign to
196   * this {@link FluxObjective}.
197   <p>
198   * <p>
199 * @note Attempting to add an object to an {@link SBMLDocument} having a different
200 * combination of SBML Level, Version and XML namespaces than the object
201 * itself will result in an error at the time a caller attempts to make the
202 * addition.  A parent object must have compatible Level, Version and XML
203 * namespaces.  (Strictly speaking, a parent may also have more XML
204 * namespaces than a child, but the reverse is not permitted.)  The
205 * restriction is necessary to ensure that an SBML model has a consistent
206 * overall structure.  This requires callers to manage their objects
207 * carefully, but the benefit is increased flexibility in how models can be
208 * created by permitting callers to create objects bottom-up if desired.  In
209 * situations where objects are not yet attached to parents (e.g.,
210 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
211 * libSBML determine such things as whether it is valid to assign a
212 * particular value to an attribute.  For packages, this means that the 
213 * parent object to which this package element is being added must have
214 * been created with the package namespace, or that the package namespace
215 * was added to it, even if that parent is not a package object itself.
216   */ public
217 FluxBound(long level) throws org.sbml.libsbml.SBMLConstructorException {
218    this(libsbmlJNI.new_FluxBound__SWIG_2(level), true);
219  }
220
221  
222/**
223   * Creates a new {@link FbcAssociation} with the given SBML Level, Version, and
224   * &ldquo;fbc&rdquo;package version.
225   <p>
226   * @param level a long integer, the SBML Level to assign to this
227   * {@link FluxObjective}.
228   <p>
229   * @param version a long integer, the SBML Version to assign to this
230   * {@link FluxObjective}.
231   <p>
232   * @param pkgVersion a long integer, the SBML Fbc Version to assign to
233   * this {@link FluxObjective}.
234   <p>
235   * <p>
236 * @note Attempting to add an object to an {@link SBMLDocument} having a different
237 * combination of SBML Level, Version and XML namespaces than the object
238 * itself will result in an error at the time a caller attempts to make the
239 * addition.  A parent object must have compatible Level, Version and XML
240 * namespaces.  (Strictly speaking, a parent may also have more XML
241 * namespaces than a child, but the reverse is not permitted.)  The
242 * restriction is necessary to ensure that an SBML model has a consistent
243 * overall structure.  This requires callers to manage their objects
244 * carefully, but the benefit is increased flexibility in how models can be
245 * created by permitting callers to create objects bottom-up if desired.  In
246 * situations where objects are not yet attached to parents (e.g.,
247 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
248 * libSBML determine such things as whether it is valid to assign a
249 * particular value to an attribute.  For packages, this means that the 
250 * parent object to which this package element is being added must have
251 * been created with the package namespace, or that the package namespace
252 * was added to it, even if that parent is not a package object itself.
253   */ public
254 FluxBound() throws org.sbml.libsbml.SBMLConstructorException {
255    this(libsbmlJNI.new_FluxBound__SWIG_3(), true);
256  }
257
258  
259/**
260   * Creates a new {@link FluxBound} with the given {@link FbcPkgNamespaces} object.
261   <p>
262   * <p>
263 * The package namespaces object used in this constructor is derived from a
264 * {@link SBMLNamespaces} object, which encapsulates SBML Level/Version/namespaces
265 * information.  It is used to communicate the SBML Level, Version, and 
266 * package version and name information used in addition to SBML Level&nbsp;3 Core.  A
267 * common approach to using libSBML's {@link SBMLNamespaces} facilities is to create an
268 * package namespace object somewhere in a program once, then hand that object
269 * as needed to object constructors of that package that accept it as and
270 * argument, such as this one.
271   <p>
272   * @param fbcns the {@link FbcPkgNamespaces} object.
273   <p>
274   * <p>
275 * @note Attempting to add an object to an {@link SBMLDocument} having a different
276 * combination of SBML Level, Version and XML namespaces than the object
277 * itself will result in an error at the time a caller attempts to make the
278 * addition.  A parent object must have compatible Level, Version and XML
279 * namespaces.  (Strictly speaking, a parent may also have more XML
280 * namespaces than a child, but the reverse is not permitted.)  The
281 * restriction is necessary to ensure that an SBML model has a consistent
282 * overall structure.  This requires callers to manage their objects
283 * carefully, but the benefit is increased flexibility in how models can be
284 * created by permitting callers to create objects bottom-up if desired.  In
285 * situations where objects are not yet attached to parents (e.g.,
286 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
287 * libSBML determine such things as whether it is valid to assign a
288 * particular value to an attribute.  For packages, this means that the 
289 * parent object to which this package element is being added must have
290 * been created with the package namespace, or that the package namespace
291 * was added to it, even if that parent is not a package object itself.
292   */ public
293 FluxBound(FbcPkgNamespaces fbcns) throws org.sbml.libsbml.SBMLConstructorException {
294    this(libsbmlJNI.new_FluxBound__SWIG_4(FbcPkgNamespaces.getCPtr(fbcns), fbcns), true);
295  }
296
297  
298/**
299   * Copy constructor.
300   <p>
301   * @param source the instance to copy.
302   */ public
303 FluxBound(FluxBound source) throws org.sbml.libsbml.SBMLConstructorException {
304    this(libsbmlJNI.new_FluxBound__SWIG_5(FluxBound.getCPtr(source), source), true);
305  }
306
307  
308/**
309   * Returns the value of the 'id' attribute of this {@link FluxBound}.
310   <p>
311   * @note Because of the inconsistent behavior of this function with 
312   * respect to assignments and rules, it is now recommended to
313   * use the getIdAttribute() function instead.
314   <p>
315   * <p>
316 * The identifier given by an object's 'id' attribute value
317 * is used to identify the object within the SBML model definition.
318 * Other objects can refer to the component using this identifier.  The
319 * data type of 'id' is always <code>SId</code> or a type derived
320 * from that, such as <code>UnitSId</code>, depending on the object in 
321 * question.  All data types are defined as follows:
322 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
323 *   letter .= 'a'..'z','A'..'Z'
324 *   digit  .= '0'..'9'
325 *   idChar .= letter | digit | '_'
326 *   SId    .= ( letter | '_' ) idChar*
327 * </pre>
328 <p>
329 * The characters <code>(</code> and <code>)</code> are used for grouping, the
330 * character <code>*</code> 'zero or more times', and the character
331 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
332 * determined by an exact character sequence match; i.e., comparisons must be
333 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
334 * <code>SIdRef</code>, and derived types.
335 <p>
336 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
337 * moved to {@link SBase} directly, instead of being defined individually for many
338 * (but not all) objects.  Libsbml has for a long time provided functions
339 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
340 * would fail or otherwise return empty strings if executed on any object 
341 * for which those attributes were not defined.  Now that all {@link SBase} objects 
342 * define those attributes, those functions now succeed for any object with 
343 * the appropriate level and version.
344 <p>
345 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
346 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
347 * functions (though not the setId() or unsetId() functions) would instead 
348 * reference the value of the 'variable' attribute (for the rules and event 
349 * assignments) or the 'symbol' attribute (for initial assignments).  
350 * The {@link AlgebraicRule} fell into this category as well, though because it 
351 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
352 * always return an empty string, and isSetId() would always return <code>false.</code>
353 * For this reason, four new functions are now provided 
354 * (getIdAttribute(), setIdAttribute(String), 
355 * isSetIdAttribute(), and unsetIdAttribute()) that will always
356 * act on the actual 'id' attribute, regardless of the object's type.  The
357 * new functions should be used instead of the old ones unless the old behavior
358 * is somehow necessary.
359 <p>
360 * Regardless of the level and version of the SBML, these functions allow
361 * client applications to use more generalized code in some situations 
362 * (for instance, when manipulating objects that are all known to have 
363 * identifiers).  If the object in question does not posess an 'id' attribute 
364 * according to the SBML specification for the Level and Version in use,
365 * libSBML will not allow the identifier to be set, nor will it read or 
366 * write 'id' attributes for those objects.
367   <p>
368   * @return the id of this {@link FluxBound}.
369   <p>
370   * @see #getIdAttribute()
371   * @see #setIdAttribute(String sid)
372   * @see #isSetIdAttribute()
373   * @see #unsetIdAttribute()
374   */ public
375 String getId() {
376    return libsbmlJNI.FluxBound_getId(swigCPtr, this);
377  }
378
379  
380/**
381   * Predicate returning <code>true</code> if this {@link FluxBound}'s 'id' attribute is set.
382   <p>
383   * <p>
384 * @note Because of the inconsistent behavior of this function with 
385 * respect to assignments and rules, it is now recommended to
386 * use the isSetIdAttribute() function instead.
387 <p>
388 * <p>
389 * The identifier given by an object's 'id' attribute value
390 * is used to identify the object within the SBML model definition.
391 * Other objects can refer to the component using this identifier.  The
392 * data type of 'id' is always <code>SId</code> or a type derived
393 * from that, such as <code>UnitSId</code>, depending on the object in 
394 * question.  All data types are defined as follows:
395 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
396 *   letter .= 'a'..'z','A'..'Z'
397 *   digit  .= '0'..'9'
398 *   idChar .= letter | digit | '_'
399 *   SId    .= ( letter | '_' ) idChar*
400 * </pre>
401 <p>
402 * The characters <code>(</code> and <code>)</code> are used for grouping, the
403 * character <code>*</code> 'zero or more times', and the character
404 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
405 * determined by an exact character sequence match; i.e., comparisons must be
406 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
407 * <code>SIdRef</code>, and derived types.
408 <p>
409 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
410 * moved to {@link SBase} directly, instead of being defined individually for many
411 * (but not all) objects.  Libsbml has for a long time provided functions
412 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
413 * would fail or otherwise return empty strings if executed on any object 
414 * for which those attributes were not defined.  Now that all {@link SBase} objects 
415 * define those attributes, those functions now succeed for any object with 
416 * the appropriate level and version.
417 <p>
418 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
419 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
420 * functions (though not the setId() or unsetId() functions) would instead 
421 * reference the value of the 'variable' attribute (for the rules and event 
422 * assignments) or the 'symbol' attribute (for initial assignments).  
423 * The {@link AlgebraicRule} fell into this category as well, though because it 
424 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
425 * always return an empty string, and isSetId() would always return <code>false.</code>
426 * For this reason, four new functions are now provided 
427 * (getIdAttribute(), setIdAttribute(String), 
428 * isSetIdAttribute(), and unsetIdAttribute()) that will always
429 * act on the actual 'id' attribute, regardless of the object's type.  The
430 * new functions should be used instead of the old ones unless the old behavior
431 * is somehow necessary.
432 <p>
433 * Regardless of the level and version of the SBML, these functions allow
434 * client applications to use more generalized code in some situations 
435 * (for instance, when manipulating objects that are all known to have 
436 * identifiers).  If the object in question does not posess an 'id' attribute 
437 * according to the SBML specification for the Level and Version in use,
438 * libSBML will not allow the identifier to be set, nor will it read or 
439 * write 'id' attributes for those objects.
440 <p>
441 * @return <code>true</code> if the 'id' attribute of this SBML object is
442 * set, <code>false</code> otherwise.
443 <p>
444 * @see #getIdAttribute()
445 * @see #setIdAttribute(String sid)
446 * @see #unsetIdAttribute()
447 * @see #isSetIdAttribute()
448   */ public
449 boolean isSetId() {
450    return libsbmlJNI.FluxBound_isSetId(swigCPtr, this);
451  }
452
453  
454/**
455   * Sets the value of the 'id' attribute of this {@link FluxBound}.
456   <p>
457   * <p>
458 * The string <code>sid</code> is copied.
459 <p>
460 * <p>
461 * The identifier given by an object's 'id' attribute value
462 * is used to identify the object within the SBML model definition.
463 * Other objects can refer to the component using this identifier.  The
464 * data type of 'id' is always <code>SId</code> or a type derived
465 * from that, such as <code>UnitSId</code>, depending on the object in 
466 * question.  All data types are defined as follows:
467 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
468 *   letter .= 'a'..'z','A'..'Z'
469 *   digit  .= '0'..'9'
470 *   idChar .= letter | digit | '_'
471 *   SId    .= ( letter | '_' ) idChar*
472 * </pre>
473 <p>
474 * The characters <code>(</code> and <code>)</code> are used for grouping, the
475 * character <code>*</code> 'zero or more times', and the character
476 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
477 * determined by an exact character sequence match; i.e., comparisons must be
478 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
479 * <code>SIdRef</code>, and derived types.
480 <p>
481 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
482 * moved to {@link SBase} directly, instead of being defined individually for many
483 * (but not all) objects.  Libsbml has for a long time provided functions
484 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
485 * would fail or otherwise return empty strings if executed on any object 
486 * for which those attributes were not defined.  Now that all {@link SBase} objects 
487 * define those attributes, those functions now succeed for any object with 
488 * the appropriate level and version.
489 <p>
490 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
491 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
492 * functions (though not the setId() or unsetId() functions) would instead 
493 * reference the value of the 'variable' attribute (for the rules and event 
494 * assignments) or the 'symbol' attribute (for initial assignments).  
495 * The {@link AlgebraicRule} fell into this category as well, though because it 
496 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
497 * always return an empty string, and isSetId() would always return <code>false.</code>
498 * For this reason, four new functions are now provided 
499 * (getIdAttribute(), setIdAttribute(String), 
500 * isSetIdAttribute(), and unsetIdAttribute()) that will always
501 * act on the actual 'id' attribute, regardless of the object's type.  The
502 * new functions should be used instead of the old ones unless the old behavior
503 * is somehow necessary.
504 <p>
505 * Regardless of the level and version of the SBML, these functions allow
506 * client applications to use more generalized code in some situations 
507 * (for instance, when manipulating objects that are all known to have 
508 * identifiers).  If the object in question does not posess an 'id' attribute 
509 * according to the SBML specification for the Level and Version in use,
510 * libSBML will not allow the identifier to be set, nor will it read or 
511 * write 'id' attributes for those objects.
512 <p>
513 * @param sid the string to use as the identifier of this object.
514 <p>
515 * <p>
516 * @return integer value indicating success/failure of the
517 * function.   The possible values
518 * returned by this function are:
519 * <ul>
520 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
521 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
522 * <li> {@link libsbmlConstants#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE}
523 *
524 * </ul> <p>
525 * @see #getIdAttribute()
526 * @see #setIdAttribute(String sid)
527 * @see #isSetIdAttribute()
528 * @see #unsetIdAttribute()
529   */ public
530 int setId(String sid) {
531    return libsbmlJNI.FluxBound_setId(swigCPtr, this, sid);
532  }
533
534  
535/**
536   * Unsets the value of the 'id' attribute of this {@link FluxBound} object.
537   <p>
538   * <p>
539 * <p>
540 * The identifier given by an object's 'id' attribute value
541 * is used to identify the object within the SBML model definition.
542 * Other objects can refer to the component using this identifier.  The
543 * data type of 'id' is always <code>SId</code> or a type derived
544 * from that, such as <code>UnitSId</code>, depending on the object in 
545 * question.  All data types are defined as follows:
546 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
547 *   letter .= 'a'..'z','A'..'Z'
548 *   digit  .= '0'..'9'
549 *   idChar .= letter | digit | '_'
550 *   SId    .= ( letter | '_' ) idChar*
551 * </pre>
552 <p>
553 * The characters <code>(</code> and <code>)</code> are used for grouping, the
554 * character <code>*</code> 'zero or more times', and the character
555 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
556 * determined by an exact character sequence match; i.e., comparisons must be
557 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
558 * <code>SIdRef</code>, and derived types.
559 <p>
560 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
561 * moved to {@link SBase} directly, instead of being defined individually for many
562 * (but not all) objects.  Libsbml has for a long time provided functions
563 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
564 * would fail or otherwise return empty strings if executed on any object 
565 * for which those attributes were not defined.  Now that all {@link SBase} objects 
566 * define those attributes, those functions now succeed for any object with 
567 * the appropriate level and version.
568 <p>
569 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
570 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
571 * functions (though not the setId() or unsetId() functions) would instead 
572 * reference the value of the 'variable' attribute (for the rules and event 
573 * assignments) or the 'symbol' attribute (for initial assignments).  
574 * The {@link AlgebraicRule} fell into this category as well, though because it 
575 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
576 * always return an empty string, and isSetId() would always return <code>false.</code>
577 * For this reason, four new functions are now provided 
578 * (getIdAttribute(), setIdAttribute(String), 
579 * isSetIdAttribute(), and unsetIdAttribute()) that will always
580 * act on the actual 'id' attribute, regardless of the object's type.  The
581 * new functions should be used instead of the old ones unless the old behavior
582 * is somehow necessary.
583 <p>
584 * Regardless of the level and version of the SBML, these functions allow
585 * client applications to use more generalized code in some situations 
586 * (for instance, when manipulating objects that are all known to have 
587 * identifiers).  If the object in question does not posess an 'id' attribute 
588 * according to the SBML specification for the Level and Version in use,
589 * libSBML will not allow the identifier to be set, nor will it read or 
590 * write 'id' attributes for those objects.
591 <p>
592 * <p>
593 * @return integer value indicating success/failure of the
594 * function.   The possible values
595 * returned by this function are:
596 * <ul>
597 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
598 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
599 *
600 * </ul> <p>
601 * @see #getIdAttribute()
602 * @see #setIdAttribute(String sid)
603 * @see #isSetIdAttribute()
604 * @see #unsetIdAttribute()
605   */ public
606 int unsetId() {
607    return libsbmlJNI.FluxBound_unsetId(swigCPtr, this);
608  }
609
610  
611/**
612   * Returns the value of the 'name' attribute of this {@link FluxBound} object.
613   <p>
614   * <p>
615 * <p>
616 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
617 * moved to {@link SBase} directly, instead of being defined individually for many
618 * (but not all) objects.  Libsbml has for a long time provided functions
619 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
620 * would fail or otherwise return empty strings if executed on any object 
621 * for which those attributes were not defined.  Now that all {@link SBase} objects 
622 * define those attributes, those functions now succeed for any object with 
623 * the appropriate level and version.
624 <p>
625 * The 'name' attribute is
626 * optional and is not intended to be used for cross-referencing purposes
627 * within a model.  Its purpose instead is to provide a human-readable
628 * label for the component.  The data type of 'name' is the type
629 * <code>string</code> defined in XML Schema.  SBML imposes no
630 * restrictions as to the content of 'name' attributes beyond those
631 * restrictions defined by the <code>string</code> type in XML Schema.
632 <p>
633 * The recommended practice for handling 'name' is as follows.  If a
634 * software tool has the capability for displaying the content of 'name'
635 * attributes, it should display this content to the user as a
636 * component's label instead of the component's 'id'.  If the user
637 * interface does not have this capability (e.g., because it cannot
638 * display or use special characters in symbol names), or if the 'name'
639 * attribute is missing on a given component, then the user interface
640 * should display the value of the 'id' attribute instead.  (Script
641 * language interpreters are especially likely to display 'id' instead of
642 * 'name'.)
643 <p>
644 * As a consequence of the above, authors of systems that automatically
645 * generate the values of 'id' attributes should be aware some systems
646 * may display the 'id''s to the user.  Authors therefore may wish to
647 * take some care to have their software create 'id' values that are: (a)
648 * reasonably easy for humans to type and read; and (b) likely to be
649 * meaningful, for example by making the 'id' attribute be an abbreviated
650 * form of the name attribute value.
651 <p>
652 * An additional point worth mentioning is although there are
653 * restrictions on the uniqueness of 'id' values, there are no
654 * restrictions on the uniqueness of 'name' values in a model.  This
655 * allows software applications leeway in assigning component identifiers.
656 <p>
657 * Regardless of the level and version of the SBML, these functions allow
658 * client applications to use more generalized code in some situations 
659 * (for instance, when manipulating objects that are all known to have 
660 * names).  If the object in question does not posess a 'name' attribute 
661 * according to the SBML specification for the Level and Version in use,
662 * libSBML will not allow the name to be set, nor will it read or 
663 * write 'name' attributes for those objects.
664 <p>
665 * @return the name of this SBML object, or the empty string if not set or unsettable.
666 <p>
667 * @see #getIdAttribute()
668 * @see #isSetName()
669 * @see #setName(String sid)
670 * @see #unsetName()
671   */ public
672 String getName() {
673    return libsbmlJNI.FluxBound_getName(swigCPtr, this);
674  }
675
676  
677/**
678   * Predicate returning <code>true</code> if this {@link FluxBound}'s 'name' attribute is set.
679   <p>
680   * <p>
681 * <p>
682 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
683 * moved to {@link SBase} directly, instead of being defined individually for many
684 * (but not all) objects.  Libsbml has for a long time provided functions
685 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
686 * would fail or otherwise return empty strings if executed on any object 
687 * for which those attributes were not defined.  Now that all {@link SBase} objects 
688 * define those attributes, those functions now succeed for any object with 
689 * the appropriate level and version.
690 <p>
691 * The 'name' attribute is
692 * optional and is not intended to be used for cross-referencing purposes
693 * within a model.  Its purpose instead is to provide a human-readable
694 * label for the component.  The data type of 'name' is the type
695 * <code>string</code> defined in XML Schema.  SBML imposes no
696 * restrictions as to the content of 'name' attributes beyond those
697 * restrictions defined by the <code>string</code> type in XML Schema.
698 <p>
699 * The recommended practice for handling 'name' is as follows.  If a
700 * software tool has the capability for displaying the content of 'name'
701 * attributes, it should display this content to the user as a
702 * component's label instead of the component's 'id'.  If the user
703 * interface does not have this capability (e.g., because it cannot
704 * display or use special characters in symbol names), or if the 'name'
705 * attribute is missing on a given component, then the user interface
706 * should display the value of the 'id' attribute instead.  (Script
707 * language interpreters are especially likely to display 'id' instead of
708 * 'name'.)
709 <p>
710 * As a consequence of the above, authors of systems that automatically
711 * generate the values of 'id' attributes should be aware some systems
712 * may display the 'id''s to the user.  Authors therefore may wish to
713 * take some care to have their software create 'id' values that are: (a)
714 * reasonably easy for humans to type and read; and (b) likely to be
715 * meaningful, for example by making the 'id' attribute be an abbreviated
716 * form of the name attribute value.
717 <p>
718 * An additional point worth mentioning is although there are
719 * restrictions on the uniqueness of 'id' values, there are no
720 * restrictions on the uniqueness of 'name' values in a model.  This
721 * allows software applications leeway in assigning component identifiers.
722 <p>
723 * Regardless of the level and version of the SBML, these functions allow
724 * client applications to use more generalized code in some situations 
725 * (for instance, when manipulating objects that are all known to have 
726 * names).  If the object in question does not posess a 'name' attribute 
727 * according to the SBML specification for the Level and Version in use,
728 * libSBML will not allow the name to be set, nor will it read or 
729 * write 'name' attributes for those objects.
730 <p>
731 * @return <code>true</code> if the 'name' attribute of this SBML object is
732 * set, <code>false</code> otherwise.
733 <p>
734 * @see #getName()
735 * @see #setName(String sid)
736 * @see #unsetName()
737   */ public
738 boolean isSetName() {
739    return libsbmlJNI.FluxBound_isSetName(swigCPtr, this);
740  }
741
742  
743/**
744   * Sets the value of the 'name' attribute of this {@link FluxBound}.
745   <p>
746   * <p>
747 * The string in <code>name</code> is copied.
748 <p>
749 * @param name the new name for the SBML object.
750 <p>
751 * <p>
752 * @return integer value indicating success/failure of the
753 * function.   The possible values
754 * returned by this function are:
755 * <ul>
756 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
757 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
758 *
759 * </ul>
760   */ public
761 int setName(String name) {
762    return libsbmlJNI.FluxBound_setName(swigCPtr, this, name);
763  }
764
765  
766/**
767   * Unsets the value of the 'name' attribute of this {@link FluxBound} object.
768   <p>
769   * <p>
770 * <p>
771 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
772 * moved to {@link SBase} directly, instead of being defined individually for many
773 * (but not all) objects.  Libsbml has for a long time provided functions
774 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
775 * would fail or otherwise return empty strings if executed on any object 
776 * for which those attributes were not defined.  Now that all {@link SBase} objects 
777 * define those attributes, those functions now succeed for any object with 
778 * the appropriate level and version.
779 <p>
780 * The 'name' attribute is
781 * optional and is not intended to be used for cross-referencing purposes
782 * within a model.  Its purpose instead is to provide a human-readable
783 * label for the component.  The data type of 'name' is the type
784 * <code>string</code> defined in XML Schema.  SBML imposes no
785 * restrictions as to the content of 'name' attributes beyond those
786 * restrictions defined by the <code>string</code> type in XML Schema.
787 <p>
788 * The recommended practice for handling 'name' is as follows.  If a
789 * software tool has the capability for displaying the content of 'name'
790 * attributes, it should display this content to the user as a
791 * component's label instead of the component's 'id'.  If the user
792 * interface does not have this capability (e.g., because it cannot
793 * display or use special characters in symbol names), or if the 'name'
794 * attribute is missing on a given component, then the user interface
795 * should display the value of the 'id' attribute instead.  (Script
796 * language interpreters are especially likely to display 'id' instead of
797 * 'name'.)
798 <p>
799 * As a consequence of the above, authors of systems that automatically
800 * generate the values of 'id' attributes should be aware some systems
801 * may display the 'id''s to the user.  Authors therefore may wish to
802 * take some care to have their software create 'id' values that are: (a)
803 * reasonably easy for humans to type and read; and (b) likely to be
804 * meaningful, for example by making the 'id' attribute be an abbreviated
805 * form of the name attribute value.
806 <p>
807 * An additional point worth mentioning is although there are
808 * restrictions on the uniqueness of 'id' values, there are no
809 * restrictions on the uniqueness of 'name' values in a model.  This
810 * allows software applications leeway in assigning component identifiers.
811 <p>
812 * Regardless of the level and version of the SBML, these functions allow
813 * client applications to use more generalized code in some situations 
814 * (for instance, when manipulating objects that are all known to have 
815 * names).  If the object in question does not posess a 'name' attribute 
816 * according to the SBML specification for the Level and Version in use,
817 * libSBML will not allow the name to be set, nor will it read or 
818 * write 'name' attributes for those objects.
819 <p>
820 * <p>
821 * @return integer value indicating success/failure of the
822 * function.   The possible values
823 * returned by this function are:
824 * <ul>
825 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
826 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
827 *
828 * </ul> <p>
829 * @see #getName()
830 * @see #setName(String sid)
831 * @see #isSetName()
832   */ public
833 int unsetName() {
834    return libsbmlJNI.FluxBound_unsetName(swigCPtr, this);
835  }
836
837  
838/**
839   * Returns the value of the 'reaction' attribute of this {@link FluxBound} object.
840   <p>
841   * @return the value of the 'reaction' attribute of this {@link FluxBound} object.
842   */ public
843 String getReaction() {
844    return libsbmlJNI.FluxBound_getReaction(swigCPtr, this);
845  }
846
847  
848/**
849   * Predicate returning <code>true</code> if this {@link FluxBound}'s 'reaction' attribute is
850   * set.
851   <p>
852   * @return <code>true</code> if this {@link FluxBound} object's 'reaction' attribute has been
853   * set, otherwise <code>false</code> is returned.
854   */ public
855 boolean isSetReaction() {
856    return libsbmlJNI.FluxBound_isSetReaction(swigCPtr, this);
857  }
858
859  
860/**
861   * Sets the value of the 'reaction' attribute of this {@link FluxBound} object.
862   <p>
863   * <p>
864 * @return integer value indicating success/failure of the
865 * function.   The possible values
866 * returned by this function are:
867   * <ul>
868   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
869   * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
870   * </ul>
871   */ public
872 int setReaction(String reaction) {
873    return libsbmlJNI.FluxBound_setReaction(swigCPtr, this, reaction);
874  }
875
876  
877/**
878   * Unsets the value of the 'reaction' attribute of this {@link FluxBound} object.
879   <p>
880   * <p>
881 * @return integer value indicating success/failure of the
882 * function.   The possible values
883 * returned by this function are:
884   * <ul>
885   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
886   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
887   * </ul>
888   */ public
889 int unsetReaction() {
890    return libsbmlJNI.FluxBound_unsetReaction(swigCPtr, this);
891  }
892
893  
894/**
895   * Returns the value of the 'operation' attribute of this {@link FluxBound} object.
896   <p>
897   * @return the value of the 'operation' attribute of this {@link FluxBound} object.
898   */ public
899 String getOperation() {
900    return libsbmlJNI.FluxBound_getOperation(swigCPtr, this);
901  }
902
903  
904/**
905   * Returns the value of the 'operation' attribute of this {@link FluxBound} object.
906   <p>
907   * @return the value of the 'operation' attribute of this {@link FluxBound} object.
908   */ public
909 int getFluxBoundOperation() {
910    return libsbmlJNI.FluxBound_getFluxBoundOperation(swigCPtr, this);
911  }
912
913  
914/**
915   * Predicate returning <code>true</code> if this {@link FluxBound}'s 'operation' attribute is
916   * set.
917   <p>
918   * @return <code>true</code> if this {@link FluxBound} object's 'operation' attribute has been set,
919   * otherwise <code>false</code> is returned.
920   */ public
921 boolean isSetOperation() {
922    return libsbmlJNI.FluxBound_isSetOperation(swigCPtr, this);
923  }
924
925  
926/**
927   * Sets the value of the 'operation' attribute of this {@link FluxBound} object.
928   <p>
929   * <p>
930 * @return integer value indicating success/failure of the
931 * function.   The possible values
932 * returned by this function are:
933   * <ul>
934   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
935   * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
936   * </ul>
937   */ public
938 int setOperation(String operation) {
939    return libsbmlJNI.FluxBound_setOperation__SWIG_0(swigCPtr, this, operation);
940  }
941
942  
943/**
944   * Sets the value of the 'operation' attribute of this {@link FluxBound} object.
945   <p>
946   * <p>
947 * @return integer value indicating success/failure of the
948 * function.   The possible values
949 * returned by this function are:
950   * <ul>
951   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
952   * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
953   * </ul>
954   */ public
955 int setOperation(int operation) {
956    return libsbmlJNI.FluxBound_setOperation__SWIG_1(swigCPtr, this, operation);
957  }
958
959  
960/**
961   * Unsets the value of the 'operation' attribute of this {@link FluxBound} object.
962   <p>
963   * <p>
964 * @return integer value indicating success/failure of the
965 * function.   The possible values
966 * returned by this function are:
967   * <ul>
968   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
969   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
970   * </ul>
971   */ public
972 int unsetOperation() {
973    return libsbmlJNI.FluxBound_unsetOperation(swigCPtr, this);
974  }
975
976  
977/**
978   * Returns the value of the 'value' attribute of this {@link FluxBound} object.
979   <p>
980   * @return the value of the 'value' attribute of this {@link FluxBound} object.
981   */ public
982 double getValue() {
983    return libsbmlJNI.FluxBound_getValue(swigCPtr, this);
984  }
985
986  
987/**
988   * Predicate returning <code>true</code> if this {@link FluxBound}'s 'value' attribute is
989   * set.
990   <p>
991   * @return <code>true</code> if this {@link FluxBound} object's 'value' attribute has been set,
992   * otherwise <code>false</code> is returned.
993   */ public
994 boolean isSetValue() {
995    return libsbmlJNI.FluxBound_isSetValue(swigCPtr, this);
996  }
997
998  
999/**
1000   * Sets the value of the 'value' attribute of this {@link FluxBound} object.
1001   <p>
1002   * <p>
1003 * @return integer value indicating success/failure of the
1004 * function.   The possible values
1005 * returned by this function are:
1006   * <ul>
1007   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
1008   * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
1009   * </ul>
1010   */ public
1011 int setValue(double value) {
1012    return libsbmlJNI.FluxBound_setValue(swigCPtr, this, value);
1013  }
1014
1015  
1016/**
1017   * Unsets the value of the 'value' attribute of this {@link FluxBound} object.
1018   <p>
1019   * <p>
1020 * @return integer value indicating success/failure of the
1021 * function.   The possible values
1022 * returned by this function are:
1023   * <ul>
1024   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
1025   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
1026   * </ul>
1027   */ public
1028 int unsetValue() {
1029    return libsbmlJNI.FluxBound_unsetValue(swigCPtr, this);
1030  }
1031
1032  
1033/**
1034   * <p>
1035 * Replaces all uses of a given <code>SIdRef</code> type attribute value with another
1036 * value.
1037 <p>
1038 * <p>
1039 * In SBML, object identifiers are of a data type called <code>SId</code>.
1040 * In SBML Level&nbsp;3, an explicit data type called <code>SIdRef</code> was
1041 * introduced for attribute values that refer to <code>SId</code> values; in
1042 * previous Levels of SBML, this data type did not exist and attributes were
1043 * simply described to as 'referring to an identifier', but the effective
1044 * data type was the same as <code>SIdRef</code> in Level&nbsp;3.  These and
1045 * other methods of libSBML refer to the type <code>SIdRef</code> for all
1046 * Levels of SBML, even if the corresponding SBML specification did not
1047 * explicitly name the data type.
1048 <p>
1049 * This method works by looking at all attributes and (if appropriate)
1050 * mathematical formulas in MathML content, comparing the referenced
1051 * identifiers to the value of <code>oldid</code>.  If any matches are found, the
1052 * matching values are replaced with <code>newid</code>.  The method does <em>not</em>
1053 * descend into child elements.
1054 <p>
1055 * @param oldid the old identifier.
1056 * @param newid the new identifier.
1057   */ public
1058 void renameSIdRefs(String oldid, String newid) {
1059    libsbmlJNI.FluxBound_renameSIdRefs(swigCPtr, this, oldid, newid);
1060  }
1061
1062  
1063/**
1064   * Returns the XML element name of this object.
1065   <p>
1066   * For {@link FluxBound}, the XML element name is always <code>'fluxBound'.</code>
1067   <p>
1068   * @return the name of this element, i.e. <code>'fluxBound'.</code>
1069   */ public
1070 String getElementName() {
1071    return libsbmlJNI.FluxBound_getElementName(swigCPtr, this);
1072  }
1073
1074  
1075/**
1076   * Creates and returns a deep copy of this {@link FluxBound} object.
1077   <p>
1078   * @return a (deep) copy of this {@link FluxBound} object.
1079   */ public
1080 FluxBound cloneObject() {
1081    long cPtr = libsbmlJNI.FluxBound_cloneObject(swigCPtr, this);
1082    return (cPtr == 0) ? null : new FluxBound(cPtr, true);
1083  }
1084
1085  
1086/**
1087   * Returns the libSBML type code of this object instance.
1088   <p>
1089   * <p>
1090 * LibSBML attaches an identifying code to every kind of SBML object.  These
1091 * are integer constants known as <em>SBML type codes</em>.  The names of all
1092 * the codes begin with the characters <code>SBML_</code>.
1093 * In the Java language interface for libSBML, the
1094 * type codes are defined as static integer constants in the interface class
1095 * {@link libsbmlConstants}.    Note that different Level&nbsp;3
1096 * package plug-ins may use overlapping type codes; to identify the package
1097 * to which a given object belongs, call the <code>getPackageName()</code>
1098 * method on the object.
1099   <p>
1100   * @return the SBML type code for this object:
1101   * {@link libsbmlConstants#SBML_FBC_FLUXBOUND SBML_FBC_FLUXBOUND}.
1102   <p>
1103   * <p>
1104 * @warning <span class='warning'>The specific integer values of the possible
1105 * type codes may be reused by different libSBML plug-ins for SBML Level&nbsp;3.
1106 * packages,  To fully identify the correct code, <strong>it is necessary to
1107 * invoke both getTypeCode() and getPackageName()</strong>.</span>
1108   <p>
1109   * @see #getElementName()
1110   * @see #getPackageName()
1111   */ public
1112 int getTypeCode() {
1113    return libsbmlJNI.FluxBound_getTypeCode(swigCPtr, this);
1114  }
1115
1116  
1117/** * @internal */ public
1118 void enablePackageInternal(String pkgURI, String pkgPrefix, boolean flag) {
1119    libsbmlJNI.FluxBound_enablePackageInternal(swigCPtr, this, pkgURI, pkgPrefix, flag);
1120  }
1121
1122}