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-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 3 <a href='../../../extensions-summary.html#comp'>Hierarchical Model Composition</a> 016 * (“comp”) 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—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 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 3 Version 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 3 Version 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 3 Version 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 3 Version 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 3 Version 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 3 Version 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 3 Version 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 3 857 * package plug-ins may use overlapping type codes; to identify the package 858 * to which a given object belongs, call the 859 * <code>{@link SBase#getPackageName()} 860 * </code> 861 * method on the object. 862 <p> 863 * @return the SBML type code for this object: 864 * {@link libsbmlConstants#SBML_COMP_PORT SBML_COMP_PORT}. 865 <p> 866 * <p> 867 * @warning <span class='warning'>The specific integer values of the possible 868 * type codes may be reused by different libSBML plug-ins for SBML Level 3. 869 * packages, To fully identify the correct code, <strong>it is necessary to 870 * invoke both getTypeCode() and getPackageName()</strong>.</span> 871 <p> 872 * @see #getElementName() 873 * @see #getPackageName() 874 */ public 875 int getTypeCode() { 876 return libsbmlJNI.Port_getTypeCode(swigCPtr, this); 877 } 878 879 880/** 881 * Finds and stores the referenced object by finding its {@link Model} parent, 882 * calling 'getReferencedElementFrom()' on that model, and storing the 883 * result. 884 <p> 885 * <p> 886 * @return integer value indicating success/failure of the 887 * function. The possible values 888 * returned by this function are: 889 * <ul> 890 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 891 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 892 * </ul> 893 */ public 894 int saveReferencedElement() { 895 return libsbmlJNI.Port_saveReferencedElement(swigCPtr, this); 896 } 897 898 899/** 900 * <p> 901 * Replaces all uses of a given <code>SIdRef</code> type attribute value with another 902 * value. 903 <p> 904 * <p> 905 * In SBML, object identifiers are of a data type called <code>SId</code>. 906 * In SBML Level 3, an explicit data type called <code>SIdRef</code> was 907 * introduced for attribute values that refer to <code>SId</code> values; in 908 * previous Levels of SBML, this data type did not exist and attributes were 909 * simply described to as 'referring to an identifier', but the effective 910 * data type was the same as <code>SIdRef</code> in Level 3. These and 911 * other methods of libSBML refer to the type <code>SIdRef</code> for all 912 * Levels of SBML, even if the corresponding SBML specification did not 913 * explicitly name the data type. 914 <p> 915 * This method works by looking at all attributes and (if appropriate) 916 * mathematical formulas in MathML content, comparing the referenced 917 * identifiers to the value of <code>oldid</code>. If any matches are found, the 918 * matching values are replaced with <code>newid</code>. The method does <em>not</em> 919 * descend into child elements. 920 <p> 921 * @param oldid the old identifier. 922 * @param newid the new identifier. 923 */ public 924 void renameSIdRefs(String oldid, String newid) { 925 libsbmlJNI.Port_renameSIdRefs(swigCPtr, this, oldid, newid); 926 } 927 928 929/** 930 * <p> 931 * Replaces all uses of a given <code>UnitSIdRef</code> type attribute value with 932 * another value. 933 <p> 934 * <p> 935 * In SBML, unit definitions have identifiers of type <code>UnitSId</code>. In 936 * SBML Level 3, an explicit data type called <code>UnitSIdRef</code> was 937 * introduced for attribute values that refer to <code>UnitSId</code> values; in 938 * previous Levels of SBML, this data type did not exist and attributes were 939 * simply described to as 'referring to a unit identifier', but the effective 940 * data type was the same as <code>UnitSIdRef</code> in Level 3. These and 941 * other methods of libSBML refer to the type <code>UnitSIdRef</code> for all 942 * Levels of SBML, even if the corresponding SBML specification did not 943 * explicitly name the data type. 944 <p> 945 * This method works by looking at all unit identifier attribute values 946 * (including, if appropriate, inside mathematical formulas), comparing the 947 * referenced unit identifiers to the value of <code>oldid</code>. If any matches 948 * are found, the matching values are replaced with <code>newid</code>. The method 949 * does <em>not</em> descend into child elements. 950 <p> 951 * @param oldid the old identifier. 952 * @param newid the new identifier. 953 */ public 954 void renameUnitSIdRefs(String oldid, String newid) { 955 libsbmlJNI.Port_renameUnitSIdRefs(swigCPtr, this, oldid, newid); 956 } 957 958 959/** 960 * <p> 961 * Replaces all uses of a given meta identifier attribute value with 962 * another value. 963 <p> 964 * <p> 965 * In SBML, object 'meta' identifiers are of the XML data type <code>ID</code>; 966 * the SBML object attribute itself is typically named <code>metaid</code>. All 967 * attributes that hold values <em>referring</em> to values of type 968 * <code>ID</code> are of the XML data type <code>IDREF</code>. They are also 969 * sometimes informally referred to as 'metaid refs', in analogy to the 970 * SBML-defined type <code>SIdRef</code>. 971 <p> 972 * This method works by looking at all meta-identifier attribute values, 973 * comparing the identifiers to the value of <code>oldid</code>. If any matches are 974 * found, the matching identifiers are replaced with <code>newid</code>. The method 975 * does <em>not</em> descend into child elements. 976 <p> 977 * @param oldid the old identifier. 978 * @param newid the new identifier. 979 */ public 980 void renameMetaIdRefs(String oldid, String newid) { 981 libsbmlJNI.Port_renameMetaIdRefs(swigCPtr, this, oldid, newid); 982 } 983 984}