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 Deletion of an object from a submodel. 014 <p> 015 * The {@link Deletion} class was introduced by the SBML Level 3 <a href='../../../extensions-summary.html#comp'>Hierarchical Model Composition</a> 016 * (“comp”) package to allow elements of submodels to be removed 017 * before instantiation. 018<p> 019 * The {@link Deletion} object class is used to define a deletion operation 020 * to be applied when a submodel instantiates a model definition. 021 * Deletions may be useful in hierarchical model composition scenarios for 022 * various reasons. For example, some components in a submodel may be 023 * redundant in the composed model, perhaps because the same features are 024 * implemented in a different way in the new model. 025<p> 026 * Deletions function as follows. When the {@link Model} to which the {@link Submodel} 027 * object refers (via the 'modelRef' attribute) is read and processed for 028 * inclusion into the composed model, each {@link Deletion} object identifies an 029 * object to remove from that {@link Model} instance. The resulting submodel 030 * instance consists of everything in the {@link Model} object instance minus the 031 * entities referenced by the list of {@link Deletion} objects. 032 <p> 033 * As might be expected, deletions can have wide-ranging implications, 034 * especially when the object deleted has substantial substructure, as in 035 * the case of reactions. The following are rules regarding deletions and 036 * their effects. 037 <p> 038 * <ul> 039 * <li> An object that has been deleted is considered inaccessible. 040 * Any element that has been deleted (or replaced) 041 * may not be referenced by an {@link SBaseRef} object. 042 * <li> If the deleted object has child objects and other structures, the 043 * child objects and substructure are also considered to be deleted. 044 * <li> It is not an error to delete explicitly an object that is already 045 * deleted by implication (for example as a result of the second point 046 * above). The resulting model is the same. 047 * <li> If the deleted object is from an SBML namespace that is not 048 * understood by the interpreter, the deletion must be ignored—the 049 * object will not need to be deleted, as the interpreter could not 050 * understand the package. If an interpreter cannot tell whether 051 * a referenced object does not exist or if exists in an unparsed namespace 052 * it may produce a warning. 053 * 054 * </ul> <p> 055 * The {@link Deletion} object class is subclassed from {@link SBaseRef}, and reuses all the 056 * machinery provided by {@link SBaseRef}. In addition, it defines two optional 057 * attributes, 'id' and 'name'. The 'id' attribute can be used to give an 058 * identifier to a given deletion operation. The identifier has no 059 * mathematical meaning, but it may be useful for creating submodels that 060 * can be manipulated more directly by other submodels. (Indeed, it is 061 * legitimate for an enclosing model definition to delete a deletion!) 062 <p> 063 * The optional 'name' attribute is provided on {@link Deletion} for the 064 * same reason it is provided on other elements that have identifiers; 065 * viz., to provide for the possibility of giving a human-readable name to 066 * the object. The name may be useful in situations when deletions are 067 * displayed to modelers. 068 */ 069 070public class Deletion extends SBaseRef { 071 private long swigCPtr; 072 073 protected Deletion(long cPtr, boolean cMemoryOwn) 074 { 075 super(libsbmlJNI.Deletion_SWIGUpcast(cPtr), cMemoryOwn); 076 swigCPtr = cPtr; 077 } 078 079 protected static long getCPtr(Deletion obj) 080 { 081 return (obj == null) ? 0 : obj.swigCPtr; 082 } 083 084 protected static long getCPtrAndDisown (Deletion obj) 085 { 086 long ptr = 0; 087 088 if (obj != null) 089 { 090 ptr = obj.swigCPtr; 091 obj.swigCMemOwn = false; 092 } 093 094 return ptr; 095 } 096 097 protected void finalize() { 098 delete(); 099 } 100 101 public synchronized void delete() { 102 if (swigCPtr != 0) { 103 if (swigCMemOwn) { 104 swigCMemOwn = false; 105 libsbmlJNI.delete_Deletion(swigCPtr); 106 } 107 swigCPtr = 0; 108 } 109 super.delete(); 110 } 111 112 113/** 114 * Creates a new {@link Deletion} with the given level, version, and package version. 115 <p> 116 * @param level the SBML Level. 117 * @param version the Version within the SBML Level. 118 * @param pkgVersion the version of the package. 119 <p> 120 * <p> 121 * @note Attempting to add an object to an {@link SBMLDocument} having a different 122 * combination of SBML Level, Version and XML namespaces than the object 123 * itself will result in an error at the time a caller attempts to make the 124 * addition. A parent object must have compatible Level, Version and XML 125 * namespaces. (Strictly speaking, a parent may also have more XML 126 * namespaces than a child, but the reverse is not permitted.) The 127 * restriction is necessary to ensure that an SBML model has a consistent 128 * overall structure. This requires callers to manage their objects 129 * carefully, but the benefit is increased flexibility in how models can be 130 * created by permitting callers to create objects bottom-up if desired. In 131 * situations where objects are not yet attached to parents (e.g., 132 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 133 * libSBML determine such things as whether it is valid to assign a 134 * particular value to an attribute. For packages, this means that the 135 * parent object to which this package element is being added must have 136 * been created with the package namespace, or that the package namespace 137 * was added to it, even if that parent is not a package object itself. 138 */ public 139 Deletion(long level, long version, long pkgVersion) throws org.sbml.libsbml.SBMLConstructorException { 140 this(libsbmlJNI.new_Deletion__SWIG_0(level, version, pkgVersion), true); 141 } 142 143 144/** 145 * Creates a new {@link Deletion} with the given level, version, and package version. 146 <p> 147 * @param level the SBML Level. 148 * @param version the Version within the SBML Level. 149 * @param pkgVersion the version of the package. 150 <p> 151 * <p> 152 * @note Attempting to add an object to an {@link SBMLDocument} having a different 153 * combination of SBML Level, Version and XML namespaces than the object 154 * itself will result in an error at the time a caller attempts to make the 155 * addition. A parent object must have compatible Level, Version and XML 156 * namespaces. (Strictly speaking, a parent may also have more XML 157 * namespaces than a child, but the reverse is not permitted.) The 158 * restriction is necessary to ensure that an SBML model has a consistent 159 * overall structure. This requires callers to manage their objects 160 * carefully, but the benefit is increased flexibility in how models can be 161 * created by permitting callers to create objects bottom-up if desired. In 162 * situations where objects are not yet attached to parents (e.g., 163 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 164 * libSBML determine such things as whether it is valid to assign a 165 * particular value to an attribute. For packages, this means that the 166 * parent object to which this package element is being added must have 167 * been created with the package namespace, or that the package namespace 168 * was added to it, even if that parent is not a package object itself. 169 */ public 170 Deletion(long level, long version) throws org.sbml.libsbml.SBMLConstructorException { 171 this(libsbmlJNI.new_Deletion__SWIG_1(level, version), true); 172 } 173 174 175/** 176 * Creates a new {@link Deletion} with the given level, version, and package version. 177 <p> 178 * @param level the SBML Level. 179 * @param version the Version within the SBML Level. 180 * @param pkgVersion the version of the package. 181 <p> 182 * <p> 183 * @note Attempting to add an object to an {@link SBMLDocument} having a different 184 * combination of SBML Level, Version and XML namespaces than the object 185 * itself will result in an error at the time a caller attempts to make the 186 * addition. A parent object must have compatible Level, Version and XML 187 * namespaces. (Strictly speaking, a parent may also have more XML 188 * namespaces than a child, but the reverse is not permitted.) The 189 * restriction is necessary to ensure that an SBML model has a consistent 190 * overall structure. This requires callers to manage their objects 191 * carefully, but the benefit is increased flexibility in how models can be 192 * created by permitting callers to create objects bottom-up if desired. In 193 * situations where objects are not yet attached to parents (e.g., 194 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 195 * libSBML determine such things as whether it is valid to assign a 196 * particular value to an attribute. For packages, this means that the 197 * parent object to which this package element is being added must have 198 * been created with the package namespace, or that the package namespace 199 * was added to it, even if that parent is not a package object itself. 200 */ public 201 Deletion(long level) throws org.sbml.libsbml.SBMLConstructorException { 202 this(libsbmlJNI.new_Deletion__SWIG_2(level), true); 203 } 204 205 206/** 207 * Creates a new {@link Deletion} with the given level, version, and package version. 208 <p> 209 * @param level the SBML Level. 210 * @param version the Version within the SBML Level. 211 * @param pkgVersion the version of the package. 212 <p> 213 * <p> 214 * @note Attempting to add an object to an {@link SBMLDocument} having a different 215 * combination of SBML Level, Version and XML namespaces than the object 216 * itself will result in an error at the time a caller attempts to make the 217 * addition. A parent object must have compatible Level, Version and XML 218 * namespaces. (Strictly speaking, a parent may also have more XML 219 * namespaces than a child, but the reverse is not permitted.) The 220 * restriction is necessary to ensure that an SBML model has a consistent 221 * overall structure. This requires callers to manage their objects 222 * carefully, but the benefit is increased flexibility in how models can be 223 * created by permitting callers to create objects bottom-up if desired. In 224 * situations where objects are not yet attached to parents (e.g., 225 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 226 * libSBML determine such things as whether it is valid to assign a 227 * particular value to an attribute. For packages, this means that the 228 * parent object to which this package element is being added must have 229 * been created with the package namespace, or that the package namespace 230 * was added to it, even if that parent is not a package object itself. 231 */ public 232 Deletion() throws org.sbml.libsbml.SBMLConstructorException { 233 this(libsbmlJNI.new_Deletion__SWIG_3(), true); 234 } 235 236 237/** 238 * Creates a new {@link Deletion} with the given {@link CompPkgNamespaces} object. 239 <p> 240 * <p> 241 * The package namespaces object used in this constructor is derived from a 242 * {@link SBMLNamespaces} object, which encapsulates SBML Level/Version/namespaces 243 * information. It is used to communicate the SBML Level, Version, and 244 * package version and name information used in addition to SBML Level 3 Core. A 245 * common approach to using libSBML's {@link SBMLNamespaces} facilities is to create an 246 * package namespace object somewhere in a program once, then hand that object 247 * as needed to object constructors of that package that accept it as and 248 * argument, such as this one. 249 <p> 250 * @param compns the {@link CompPkgNamespaces} object. 251 <p> 252 * <p> 253 * @note Attempting to add an object to an {@link SBMLDocument} having a different 254 * combination of SBML Level, Version and XML namespaces than the object 255 * itself will result in an error at the time a caller attempts to make the 256 * addition. A parent object must have compatible Level, Version and XML 257 * namespaces. (Strictly speaking, a parent may also have more XML 258 * namespaces than a child, but the reverse is not permitted.) The 259 * restriction is necessary to ensure that an SBML model has a consistent 260 * overall structure. This requires callers to manage their objects 261 * carefully, but the benefit is increased flexibility in how models can be 262 * created by permitting callers to create objects bottom-up if desired. In 263 * situations where objects are not yet attached to parents (e.g., 264 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 265 * libSBML determine such things as whether it is valid to assign a 266 * particular value to an attribute. For packages, this means that the 267 * parent object to which this package element is being added must have 268 * been created with the package namespace, or that the package namespace 269 * was added to it, even if that parent is not a package object itself. 270 */ public 271 Deletion(CompPkgNamespaces compns) throws org.sbml.libsbml.SBMLConstructorException { 272 this(libsbmlJNI.new_Deletion__SWIG_4(CompPkgNamespaces.getCPtr(compns), compns), true); 273 } 274 275 276/** 277 * Copy constructor. 278 <p> 279 * @param source the {@link Deletion} instance to copy. 280 */ public 281 Deletion(Deletion source) throws org.sbml.libsbml.SBMLConstructorException { 282 this(libsbmlJNI.new_Deletion__SWIG_5(Deletion.getCPtr(source), source), true); 283 } 284 285 286/** 287 * Creates and returns a deep copy of this {@link Deletion} object. 288 <p> 289 * @return a (deep) copy of this {@link Deletion} object. 290 */ public 291 SBase cloneObject() { 292 long cPtr = libsbmlJNI.Deletion_cloneObject(swigCPtr, this); 293 return (cPtr == 0) ? null : new Deletion(cPtr, true); 294 } 295 296 297/** 298 * Sets the value of the 'id' attribute of this {@link Deletion}. 299 <p> 300 * <p> 301 * The string <code>sid</code> is copied. 302 <p> 303 * <p> 304 * The identifier given by an object's 'id' attribute value 305 * is used to identify the object within the SBML model definition. 306 * Other objects can refer to the component using this identifier. The 307 * data type of 'id' is always <code>SId</code> or a type derived 308 * from that, such as <code>UnitSId</code>, depending on the object in 309 * question. All data types are defined as follows: 310 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 311 * letter .= 'a'..'z','A'..'Z' 312 * digit .= '0'..'9' 313 * idChar .= letter | digit | '_' 314 * SId .= ( letter | '_' ) idChar* 315 * </pre> 316 <p> 317 * The characters <code>(</code> and <code>)</code> are used for grouping, the 318 * character <code>*</code> 'zero or more times', and the character 319 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 320 * determined by an exact character sequence match; i.e., comparisons must be 321 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 322 * <code>SIdRef</code>, and derived types. 323 <p> 324 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 325 * moved to {@link SBase} directly, instead of being defined individually for many 326 * (but not all) objects. Libsbml has for a long time provided functions 327 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 328 * would fail or otherwise return empty strings if executed on any object 329 * for which those attributes were not defined. Now that all {@link SBase} objects 330 * define those attributes, those functions now succeed for any object with 331 * the appropriate level and version. 332 <p> 333 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 334 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 335 * functions (though not the setId() or unsetId() functions) would instead 336 * reference the value of the 'variable' attribute (for the rules and event 337 * assignments) or the 'symbol' attribute (for initial assignments). 338 * The {@link AlgebraicRule} fell into this category as well, though because it 339 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 340 * always return an empty string, and isSetId() would always return <code>false.</code> 341 * For this reason, four new functions are now provided 342 * (getIdAttribute(), setIdAttribute(String), 343 * isSetIdAttribute(), and unsetIdAttribute()) that will always 344 * act on the actual 'id' attribute, regardless of the object's type. The 345 * new functions should be used instead of the old ones unless the old behavior 346 * is somehow necessary. 347 <p> 348 * Regardless of the level and version of the SBML, these functions allow 349 * client applications to use more generalized code in some situations 350 * (for instance, when manipulating objects that are all known to have 351 * identifiers). If the object in question does not posess an 'id' attribute 352 * according to the SBML specification for the Level and Version in use, 353 * libSBML will not allow the identifier to be set, nor will it read or 354 * write 'id' attributes for those objects. 355 <p> 356 * @param sid the string to use as the identifier of this object. 357 <p> 358 * <p> 359 * @return integer value indicating success/failure of the 360 * function. The possible values 361 * returned by this function are: 362 * <ul> 363 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 364 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 365 * <li> {@link libsbmlConstants#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE} 366 * 367 * </ul> <p> 368 * @see #getIdAttribute() 369 * @see #setIdAttribute(String sid) 370 * @see #isSetIdAttribute() 371 * @see #unsetIdAttribute() 372 */ public 373 int setId(String sid) { 374 return libsbmlJNI.Deletion_setId(swigCPtr, this, sid); 375 } 376 377 378/** 379 * Returns the value of the 'id' attribute of this {@link Deletion}. 380 <p> 381 * @note Because of the inconsistent behavior of this function with 382 * respect to assignments and rules, it is now recommended to 383 * use the getIdAttribute() function instead. 384 <p> 385 * <p> 386 * The identifier given by an object's 'id' attribute value 387 * is used to identify the object within the SBML model definition. 388 * Other objects can refer to the component using this identifier. The 389 * data type of 'id' is always <code>SId</code> or a type derived 390 * from that, such as <code>UnitSId</code>, depending on the object in 391 * question. All data types are defined as follows: 392 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 393 * letter .= 'a'..'z','A'..'Z' 394 * digit .= '0'..'9' 395 * idChar .= letter | digit | '_' 396 * SId .= ( letter | '_' ) idChar* 397 * </pre> 398 <p> 399 * The characters <code>(</code> and <code>)</code> are used for grouping, the 400 * character <code>*</code> 'zero or more times', and the character 401 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 402 * determined by an exact character sequence match; i.e., comparisons must be 403 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 404 * <code>SIdRef</code>, and derived types. 405 <p> 406 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 407 * moved to {@link SBase} directly, instead of being defined individually for many 408 * (but not all) objects. Libsbml has for a long time provided functions 409 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 410 * would fail or otherwise return empty strings if executed on any object 411 * for which those attributes were not defined. Now that all {@link SBase} objects 412 * define those attributes, those functions now succeed for any object with 413 * the appropriate level and version. 414 <p> 415 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 416 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 417 * functions (though not the setId() or unsetId() functions) would instead 418 * reference the value of the 'variable' attribute (for the rules and event 419 * assignments) or the 'symbol' attribute (for initial assignments). 420 * The {@link AlgebraicRule} fell into this category as well, though because it 421 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 422 * always return an empty string, and isSetId() would always return <code>false.</code> 423 * For this reason, four new functions are now provided 424 * (getIdAttribute(), setIdAttribute(String), 425 * isSetIdAttribute(), and unsetIdAttribute()) that will always 426 * act on the actual 'id' attribute, regardless of the object's type. The 427 * new functions should be used instead of the old ones unless the old behavior 428 * is somehow necessary. 429 <p> 430 * Regardless of the level and version of the SBML, these functions allow 431 * client applications to use more generalized code in some situations 432 * (for instance, when manipulating objects that are all known to have 433 * identifiers). If the object in question does not posess an 'id' attribute 434 * according to the SBML specification for the Level and Version in use, 435 * libSBML will not allow the identifier to be set, nor will it read or 436 * write 'id' attributes for those objects. 437 <p> 438 * @return the id of this {@link Deletion}. 439 <p> 440 * @see #getIdAttribute() 441 * @see #setIdAttribute(String sid) 442 * @see #isSetIdAttribute() 443 * @see #unsetIdAttribute() 444 */ public 445 String getId() { 446 return libsbmlJNI.Deletion_getId(swigCPtr, this); 447 } 448 449 450/** 451 * Predicate returning <code>true</code> or <code>false</code> depending on whether this 452 * object's 'id' attribute has been set. 453 <p> 454 * <p> 455 * @note Because of the inconsistent behavior of this function with 456 * respect to assignments and rules, it is now recommended to 457 * use the isSetIdAttribute() function instead. 458 <p> 459 * <p> 460 * The identifier given by an object's 'id' attribute value 461 * is used to identify the object within the SBML model definition. 462 * Other objects can refer to the component using this identifier. The 463 * data type of 'id' is always <code>SId</code> or a type derived 464 * from that, such as <code>UnitSId</code>, depending on the object in 465 * question. All data types are defined as follows: 466 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 467 * letter .= 'a'..'z','A'..'Z' 468 * digit .= '0'..'9' 469 * idChar .= letter | digit | '_' 470 * SId .= ( letter | '_' ) idChar* 471 * </pre> 472 <p> 473 * The characters <code>(</code> and <code>)</code> are used for grouping, the 474 * character <code>*</code> 'zero or more times', and the character 475 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 476 * determined by an exact character sequence match; i.e., comparisons must be 477 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 478 * <code>SIdRef</code>, and derived types. 479 <p> 480 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 481 * moved to {@link SBase} directly, instead of being defined individually for many 482 * (but not all) objects. Libsbml has for a long time provided functions 483 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 484 * would fail or otherwise return empty strings if executed on any object 485 * for which those attributes were not defined. Now that all {@link SBase} objects 486 * define those attributes, those functions now succeed for any object with 487 * the appropriate level and version. 488 <p> 489 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 490 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 491 * functions (though not the setId() or unsetId() functions) would instead 492 * reference the value of the 'variable' attribute (for the rules and event 493 * assignments) or the 'symbol' attribute (for initial assignments). 494 * The {@link AlgebraicRule} fell into this category as well, though because it 495 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 496 * always return an empty string, and isSetId() would always return <code>false.</code> 497 * For this reason, four new functions are now provided 498 * (getIdAttribute(), setIdAttribute(String), 499 * isSetIdAttribute(), and unsetIdAttribute()) that will always 500 * act on the actual 'id' attribute, regardless of the object's type. The 501 * new functions should be used instead of the old ones unless the old behavior 502 * is somehow necessary. 503 <p> 504 * Regardless of the level and version of the SBML, these functions allow 505 * client applications to use more generalized code in some situations 506 * (for instance, when manipulating objects that are all known to have 507 * identifiers). If the object in question does not posess an 'id' attribute 508 * according to the SBML specification for the Level and Version in use, 509 * libSBML will not allow the identifier to be set, nor will it read or 510 * write 'id' attributes for those objects. 511 <p> 512 * @return <code>true</code> if the 'id' attribute of this SBML object is 513 * set, <code>false</code> otherwise. 514 <p> 515 * @see #getIdAttribute() 516 * @see #setIdAttribute(String sid) 517 * @see #unsetIdAttribute() 518 * @see #isSetIdAttribute() 519 */ public 520 boolean isSetId() { 521 return libsbmlJNI.Deletion_isSetId(swigCPtr, this); 522 } 523 524 525/** 526 * Unsets the value of the 'id' attribute of this {@link Deletion}. 527 <p> 528 * <p> 529 * <p> 530 * The identifier given by an object's 'id' attribute value 531 * is used to identify the object within the SBML model definition. 532 * Other objects can refer to the component using this identifier. The 533 * data type of 'id' is always <code>SId</code> or a type derived 534 * from that, such as <code>UnitSId</code>, depending on the object in 535 * question. All data types are defined as follows: 536 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 537 * letter .= 'a'..'z','A'..'Z' 538 * digit .= '0'..'9' 539 * idChar .= letter | digit | '_' 540 * SId .= ( letter | '_' ) idChar* 541 * </pre> 542 <p> 543 * The characters <code>(</code> and <code>)</code> are used for grouping, the 544 * character <code>*</code> 'zero or more times', and the character 545 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 546 * determined by an exact character sequence match; i.e., comparisons must be 547 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 548 * <code>SIdRef</code>, and derived types. 549 <p> 550 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 551 * moved to {@link SBase} directly, instead of being defined individually for many 552 * (but not all) objects. Libsbml has for a long time provided functions 553 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 554 * would fail or otherwise return empty strings if executed on any object 555 * for which those attributes were not defined. Now that all {@link SBase} objects 556 * define those attributes, those functions now succeed for any object with 557 * the appropriate level and version. 558 <p> 559 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 560 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 561 * functions (though not the setId() or unsetId() functions) would instead 562 * reference the value of the 'variable' attribute (for the rules and event 563 * assignments) or the 'symbol' attribute (for initial assignments). 564 * The {@link AlgebraicRule} fell into this category as well, though because it 565 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 566 * always return an empty string, and isSetId() would always return <code>false.</code> 567 * For this reason, four new functions are now provided 568 * (getIdAttribute(), setIdAttribute(String), 569 * isSetIdAttribute(), and unsetIdAttribute()) that will always 570 * act on the actual 'id' attribute, regardless of the object's type. The 571 * new functions should be used instead of the old ones unless the old behavior 572 * is somehow necessary. 573 <p> 574 * Regardless of the level and version of the SBML, these functions allow 575 * client applications to use more generalized code in some situations 576 * (for instance, when manipulating objects that are all known to have 577 * identifiers). If the object in question does not posess an 'id' attribute 578 * according to the SBML specification for the Level and Version in use, 579 * libSBML will not allow the identifier to be set, nor will it read or 580 * write 'id' attributes for those objects. 581 <p> 582 * <p> 583 * @return integer value indicating success/failure of the 584 * function. The possible values 585 * returned by this function are: 586 * <ul> 587 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 588 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 589 * 590 * </ul> <p> 591 * @see #getIdAttribute() 592 * @see #setIdAttribute(String sid) 593 * @see #isSetIdAttribute() 594 * @see #unsetIdAttribute() 595 */ public 596 int unsetId() { 597 return libsbmlJNI.Deletion_unsetId(swigCPtr, this); 598 } 599 600 601/** 602 * Sets the value of the 'name' attribute of this {@link Deletion}. 603 <p> 604 * <p> 605 * The string in <code>name</code> is copied. 606 <p> 607 * @param name the new name for the SBML object. 608 <p> 609 * <p> 610 * @return integer value indicating success/failure of the 611 * function. The possible values 612 * returned by this function are: 613 * <ul> 614 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 615 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 616 * 617 * </ul> 618 */ public 619 int setName(String name) { 620 return libsbmlJNI.Deletion_setName(swigCPtr, this, name); 621 } 622 623 624/** 625 * Returns the value of the 'name' attribute of this {@link Deletion} object. 626 <p> 627 * <p> 628 * <p> 629 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 630 * moved to {@link SBase} directly, instead of being defined individually for many 631 * (but not all) objects. Libsbml has for a long time provided functions 632 * defined on {@link SBase} itself to get, set, and unset those attributes, which 633 * would fail or otherwise return empty strings if executed on any object 634 * for which those attributes were not defined. Now that all {@link SBase} objects 635 * define those attributes, those functions now succeed for any object with 636 * the appropriate level and version. 637 <p> 638 * The 'name' attribute is 639 * optional and is not intended to be used for cross-referencing purposes 640 * within a model. Its purpose instead is to provide a human-readable 641 * label for the component. The data type of 'name' is the type 642 * <code>string</code> defined in XML Schema. SBML imposes no 643 * restrictions as to the content of 'name' attributes beyond those 644 * restrictions defined by the <code>string</code> type in XML Schema. 645 <p> 646 * The recommended practice for handling 'name' is as follows. If a 647 * software tool has the capability for displaying the content of 'name' 648 * attributes, it should display this content to the user as a 649 * component's label instead of the component's 'id'. If the user 650 * interface does not have this capability (e.g., because it cannot 651 * display or use special characters in symbol names), or if the 'name' 652 * attribute is missing on a given component, then the user interface 653 * should display the value of the 'id' attribute instead. (Script 654 * language interpreters are especially likely to display 'id' instead of 655 * 'name'.) 656 <p> 657 * As a consequence of the above, authors of systems that automatically 658 * generate the values of 'id' attributes should be aware some systems 659 * may display the 'id''s to the user. Authors therefore may wish to 660 * take some care to have their software create 'id' values that are: (a) 661 * reasonably easy for humans to type and read; and (b) likely to be 662 * meaningful, for example by making the 'id' attribute be an abbreviated 663 * form of the name attribute value. 664 <p> 665 * An additional point worth mentioning is although there are 666 * restrictions on the uniqueness of 'id' values, there are no 667 * restrictions on the uniqueness of 'name' values in a model. This 668 * allows software applications leeway in assigning component identifiers. 669 <p> 670 * Regardless of the level and version of the SBML, these functions allow 671 * client applications to use more generalized code in some situations 672 * (for instance, when manipulating objects that are all known to have 673 * names). If the object in question does not posess a 'name' attribute 674 * according to the SBML specification for the Level and Version in use, 675 * libSBML will not allow the name to be set, nor will it read or 676 * write 'name' attributes for those objects. 677 <p> 678 * @return the name of this SBML object, or the empty string if not set or unsettable. 679 <p> 680 * @see #getIdAttribute() 681 * @see #isSetName() 682 * @see #setName(String sid) 683 * @see #unsetName() 684 */ public 685 String getName() { 686 return libsbmlJNI.Deletion_getName(swigCPtr, this); 687 } 688 689 690/** 691 * Predicate returning <code>true</code> or <code>false</code> depending on whether this 692 * object's 'name' attribute has been set. 693 <p> 694 * <p> 695 * <p> 696 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 697 * moved to {@link SBase} directly, instead of being defined individually for many 698 * (but not all) objects. Libsbml has for a long time provided functions 699 * defined on {@link SBase} itself to get, set, and unset those attributes, which 700 * would fail or otherwise return empty strings if executed on any object 701 * for which those attributes were not defined. Now that all {@link SBase} objects 702 * define those attributes, those functions now succeed for any object with 703 * the appropriate level and version. 704 <p> 705 * The 'name' attribute is 706 * optional and is not intended to be used for cross-referencing purposes 707 * within a model. Its purpose instead is to provide a human-readable 708 * label for the component. The data type of 'name' is the type 709 * <code>string</code> defined in XML Schema. SBML imposes no 710 * restrictions as to the content of 'name' attributes beyond those 711 * restrictions defined by the <code>string</code> type in XML Schema. 712 <p> 713 * The recommended practice for handling 'name' is as follows. If a 714 * software tool has the capability for displaying the content of 'name' 715 * attributes, it should display this content to the user as a 716 * component's label instead of the component's 'id'. If the user 717 * interface does not have this capability (e.g., because it cannot 718 * display or use special characters in symbol names), or if the 'name' 719 * attribute is missing on a given component, then the user interface 720 * should display the value of the 'id' attribute instead. (Script 721 * language interpreters are especially likely to display 'id' instead of 722 * 'name'.) 723 <p> 724 * As a consequence of the above, authors of systems that automatically 725 * generate the values of 'id' attributes should be aware some systems 726 * may display the 'id''s to the user. Authors therefore may wish to 727 * take some care to have their software create 'id' values that are: (a) 728 * reasonably easy for humans to type and read; and (b) likely to be 729 * meaningful, for example by making the 'id' attribute be an abbreviated 730 * form of the name attribute value. 731 <p> 732 * An additional point worth mentioning is although there are 733 * restrictions on the uniqueness of 'id' values, there are no 734 * restrictions on the uniqueness of 'name' values in a model. This 735 * allows software applications leeway in assigning component identifiers. 736 <p> 737 * Regardless of the level and version of the SBML, these functions allow 738 * client applications to use more generalized code in some situations 739 * (for instance, when manipulating objects that are all known to have 740 * names). If the object in question does not posess a 'name' attribute 741 * according to the SBML specification for the Level and Version in use, 742 * libSBML will not allow the name to be set, nor will it read or 743 * write 'name' attributes for those objects. 744 <p> 745 * @return <code>true</code> if the 'name' attribute of this SBML object is 746 * set, <code>false</code> otherwise. 747 <p> 748 * @see #getName() 749 * @see #setName(String sid) 750 * @see #unsetName() 751 */ public 752 boolean isSetName() { 753 return libsbmlJNI.Deletion_isSetName(swigCPtr, this); 754 } 755 756 757/** 758 * Unsets the value of the 'name' attribute of this {@link Deletion}. 759 <p> 760 * <p> 761 * <p> 762 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 763 * moved to {@link SBase} directly, instead of being defined individually for many 764 * (but not all) objects. Libsbml has for a long time provided functions 765 * defined on {@link SBase} itself to get, set, and unset those attributes, which 766 * would fail or otherwise return empty strings if executed on any object 767 * for which those attributes were not defined. Now that all {@link SBase} objects 768 * define those attributes, those functions now succeed for any object with 769 * the appropriate level and version. 770 <p> 771 * The 'name' attribute is 772 * optional and is not intended to be used for cross-referencing purposes 773 * within a model. Its purpose instead is to provide a human-readable 774 * label for the component. The data type of 'name' is the type 775 * <code>string</code> defined in XML Schema. SBML imposes no 776 * restrictions as to the content of 'name' attributes beyond those 777 * restrictions defined by the <code>string</code> type in XML Schema. 778 <p> 779 * The recommended practice for handling 'name' is as follows. If a 780 * software tool has the capability for displaying the content of 'name' 781 * attributes, it should display this content to the user as a 782 * component's label instead of the component's 'id'. If the user 783 * interface does not have this capability (e.g., because it cannot 784 * display or use special characters in symbol names), or if the 'name' 785 * attribute is missing on a given component, then the user interface 786 * should display the value of the 'id' attribute instead. (Script 787 * language interpreters are especially likely to display 'id' instead of 788 * 'name'.) 789 <p> 790 * As a consequence of the above, authors of systems that automatically 791 * generate the values of 'id' attributes should be aware some systems 792 * may display the 'id''s to the user. Authors therefore may wish to 793 * take some care to have their software create 'id' values that are: (a) 794 * reasonably easy for humans to type and read; and (b) likely to be 795 * meaningful, for example by making the 'id' attribute be an abbreviated 796 * form of the name attribute value. 797 <p> 798 * An additional point worth mentioning is although there are 799 * restrictions on the uniqueness of 'id' values, there are no 800 * restrictions on the uniqueness of 'name' values in a model. This 801 * allows software applications leeway in assigning component identifiers. 802 <p> 803 * Regardless of the level and version of the SBML, these functions allow 804 * client applications to use more generalized code in some situations 805 * (for instance, when manipulating objects that are all known to have 806 * names). If the object in question does not posess a 'name' attribute 807 * according to the SBML specification for the Level and Version in use, 808 * libSBML will not allow the name to be set, nor will it read or 809 * write 'name' attributes for those objects. 810 <p> 811 * <p> 812 * @return integer value indicating success/failure of the 813 * function. The possible values 814 * returned by this function are: 815 * <ul> 816 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 817 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 818 * 819 * </ul> <p> 820 * @see #getName() 821 * @see #setName(String sid) 822 * @see #isSetName() 823 */ public 824 int unsetName() { 825 return libsbmlJNI.Deletion_unsetName(swigCPtr, this); 826 } 827 828 829/** 830 * Returns the XML element name of this SBML object. 831 <p> 832 * @return the name of this element, as a text string. 833 */ public 834 String getElementName() { 835 return libsbmlJNI.Deletion_getElementName(swigCPtr, this); 836 } 837 838 839/** 840 * Returns the libSBML type code of this object instance. 841 <p> 842 * <p> 843 * LibSBML attaches an identifying code to every kind of SBML object. These 844 * are integer constants known as <em>SBML type codes</em>. The names of all 845 * the codes begin with the characters <code>SBML_</code>. 846 * In the Java language interface for libSBML, the 847 * type codes are defined as static integer constants in the interface class 848 * {@link libsbmlConstants}. Note that different Level 3 849 * package plug-ins may use overlapping type codes; to identify the package 850 * to which a given object belongs, call the 851 * <code>{@link SBase#getPackageName()} 852 * </code> 853 * method on the object. 854 <p> 855 * @return the SBML type code for this object: 856 * {@link libsbmlConstants#SBML_COMP_DELETION SBML_COMP_DELETION}. 857 <p> 858 * <p> 859 * @warning <span class='warning'>The specific integer values of the possible 860 * type codes may be reused by different libSBML plug-ins for SBML Level 3. 861 * packages, To fully identify the correct code, <strong>it is necessary to 862 * invoke both getTypeCode() and getPackageName()</strong>.</span> 863 <p> 864 * @see #getElementName() 865 * @see #getPackageName() 866 */ public 867 int getTypeCode() { 868 return libsbmlJNI.Deletion_getTypeCode(swigCPtr, this); 869 } 870 871 872/** 873 * Finds and stores the referenced object. It finds its {@link Submodel} parent, 874 * gets its instantiated {@link Model} object, calls 875 * 'getReferencedElementFrom()' using that model, and stores the result. 876 <p> 877 * <p> 878 * @return integer value indicating success/failure of the 879 * function. The possible values 880 * returned by this function are: 881 * <ul> 882 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 883 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 884 * </ul> 885 */ public 886 int saveReferencedElement() { 887 return libsbmlJNI.Deletion_saveReferencedElement(swigCPtr, this); 888 } 889 890}