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