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