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 * A <em>compartment type</em> in SBML Level 2. 013 <p> 014 * SBML Level 2 Versions 2–4 provide the <em>compartment 015 * type</em> as a grouping construct that can be used to establish a 016 * relationship between multiple {@link Compartment} objects. A {@link CompartmentType} 017 * object only has an identity, and this identity can only be used to 018 * indicate that particular {@link Compartment} objects in the model belong to this 019 * type. This may be useful for conveying a modeling intention, such as 020 * when a model contains many similar compartments, either by their 021 * biological function or the reactions they carry. Without a compartment 022 * type construct, it would be impossible within SBML itself to indicate 023 * that all of the compartments share an underlying conceptual relationship 024 * because each SBML compartment must be given a unique and separate 025 * identity. A {@link CompartmentType} has no mathematical meaning in 026 * SBML—it has no effect on a model's mathematical interpretation. 027 * Simulators and other numerical analysis software may ignore 028 * {@link CompartmentType} definitions and references to them in a model. 029 <p> 030 * There is no mechanism in SBML Level 2 for representing hierarchies of 031 * compartment types. One {@link CompartmentType} instance cannot be the subtype 032 * of another {@link CompartmentType} instance; SBML provides no means of defining 033 * such relationships. 034 <p> 035 * As with other major structures in SBML, {@link CompartmentType} has a mandatory 036 * attribute, 'id', used to give the compartment type an identifier. The 037 * identifier must be a text string conforming to the identifer syntax 038 * permitted in SBML. {@link CompartmentType} also has an optional 'name' 039 * attribute, of type <code>string.</code> The 'id' and 'name' must be used 040 * according to the guidelines described in the SBML specification (e.g., 041 * Section 3.3 in the Level 2 Version 4 specification). 042 <p> 043 * {@link CompartmentType} was introduced in SBML Level 2 Version 2. It is not 044 * available in SBML Level 1 nor in Level 3. 045 <p> 046 * @see Compartment 047 * @see ListOfCompartmentTypes 048 * @see SpeciesType 049 * @see ListOfSpeciesTypes 050 */ 051 052public class CompartmentType extends SBase { 053 private long swigCPtr; 054 055 protected CompartmentType(long cPtr, boolean cMemoryOwn) 056 { 057 super(libsbmlJNI.CompartmentType_SWIGUpcast(cPtr), cMemoryOwn); 058 swigCPtr = cPtr; 059 } 060 061 protected static long getCPtr(CompartmentType obj) 062 { 063 return (obj == null) ? 0 : obj.swigCPtr; 064 } 065 066 protected static long getCPtrAndDisown (CompartmentType obj) 067 { 068 long ptr = 0; 069 070 if (obj != null) 071 { 072 ptr = obj.swigCPtr; 073 obj.swigCMemOwn = false; 074 } 075 076 return ptr; 077 } 078 079 protected void finalize() { 080 delete(); 081 } 082 083 public synchronized void delete() { 084 if (swigCPtr != 0) { 085 if (swigCMemOwn) { 086 swigCMemOwn = false; 087 libsbmlJNI.delete_CompartmentType(swigCPtr); 088 } 089 swigCPtr = 0; 090 } 091 super.delete(); 092 } 093 094 095/** 096 * Creates a new {@link CompartmentType} object using the given SBML <code>level</code> and 097 * <code>version</code> values. 098 <p> 099 * @param level a long integer, the SBML Level to assign to this 100 * {@link CompartmentType}. 101 <p> 102 * @param version a long integer, the SBML Version to assign to this 103 * {@link CompartmentType}. 104 <p> 105 * <p> 106 * @throws SBMLConstructorException 107 * Thrown if the given <code>level</code> and <code>version</code> combination are invalid 108 * or if this object is incompatible with the given level and version. 109 <p> 110 * <p> 111 * @note Attempting to add an object to an {@link SBMLDocument} having a different 112 * combination of SBML Level, Version and XML namespaces than the object 113 * itself will result in an error at the time a caller attempts to make the 114 * addition. A parent object must have compatible Level, Version and XML 115 * namespaces. (Strictly speaking, a parent may also have more XML 116 * namespaces than a child, but the reverse is not permitted.) The 117 * restriction is necessary to ensure that an SBML model has a consistent 118 * overall structure. This requires callers to manage their objects 119 * carefully, but the benefit is increased flexibility in how models can be 120 * created by permitting callers to create objects bottom-up if desired. In 121 * situations where objects are not yet attached to parents (e.g., 122 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 123 * libSBML determine such things as whether it is valid to assign a 124 * particular value to an attribute. 125 */ public 126 CompartmentType(long level, long version) throws org.sbml.libsbml.SBMLConstructorException { 127 this(libsbmlJNI.new_CompartmentType__SWIG_0(level, version), true); 128 } 129 130 131/** 132 * Creates a new {@link CompartmentType} object using the given {@link SBMLNamespaces} 133 * object <code>sbmlns</code>. 134 <p> 135 * <p> 136 * The {@link SBMLNamespaces} object encapsulates SBML Level/Version/namespaces 137 * information. It is used to communicate the SBML Level, Version, and (in 138 * Level 3) packages used in addition to SBML Level 3 Core. A 139 * common approach to using libSBML's {@link SBMLNamespaces} facilities is to create an 140 * {@link SBMLNamespaces} object somewhere in a program once, then hand that object 141 * as needed to object constructors that accept {@link SBMLNamespaces} as arguments. 142 <p> 143 * It is worth emphasizing that although this constructor does not take an 144 * identifier argument, in SBML Level 2 and beyond, the 'id' 145 * (identifier) attribute of a {@link CompartmentType} object is required to have a 146 * value. Thus, callers are cautioned to assign a value after calling this 147 * constructor. Setting the identifier can be accomplished using the 148 * method setId(String). 149 <p> 150 * @param sbmlns an {@link SBMLNamespaces} object. 151 <p> 152 * <p> 153 * @throws SBMLConstructorException 154 * Thrown if the given <code>sbmlns</code> is inconsistent or incompatible 155 * with this object. 156 <p> 157 * <p> 158 * @note Attempting to add an object to an {@link SBMLDocument} having a different 159 * combination of SBML Level, Version and XML namespaces than the object 160 * itself will result in an error at the time a caller attempts to make the 161 * addition. A parent object must have compatible Level, Version and XML 162 * namespaces. (Strictly speaking, a parent may also have more XML 163 * namespaces than a child, but the reverse is not permitted.) The 164 * restriction is necessary to ensure that an SBML model has a consistent 165 * overall structure. This requires callers to manage their objects 166 * carefully, but the benefit is increased flexibility in how models can be 167 * created by permitting callers to create objects bottom-up if desired. In 168 * situations where objects are not yet attached to parents (e.g., 169 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help 170 * libSBML determine such things as whether it is valid to assign a 171 * particular value to an attribute. 172 */ public 173 CompartmentType(SBMLNamespaces sbmlns) throws org.sbml.libsbml.SBMLConstructorException { 174 this(libsbmlJNI.new_CompartmentType__SWIG_1(SBMLNamespaces.getCPtr(sbmlns), sbmlns), true); 175 } 176 177 178/** 179 * Copy constructor; creates a copy of this {@link CompartmentType} object. 180 <p> 181 * @param orig the object to copy. 182 */ public 183 CompartmentType(CompartmentType orig) throws org.sbml.libsbml.SBMLConstructorException { 184 this(libsbmlJNI.new_CompartmentType__SWIG_2(CompartmentType.getCPtr(orig), orig), true); 185 } 186 187 188/** 189 * Creates and returns a deep copy of this {@link CompartmentType} object. 190 <p> 191 * @return the (deep) copy of this {@link CompartmentType} object. 192 */ public 193 CompartmentType cloneObject() { 194 long cPtr = libsbmlJNI.CompartmentType_cloneObject(swigCPtr, this); 195 return (cPtr == 0) ? null : new CompartmentType(cPtr, true); 196 } 197 198 199/** 200 * Returns the value of the 'id' attribute of this {@link CompartmentType}. 201 <p> 202 * @note Because of the inconsistent behavior of this function with 203 * respect to assignments and rules, it is now recommended to 204 * use the getIdAttribute() function instead. 205 <p> 206 * <p> 207 * The identifier given by an object's 'id' attribute value 208 * is used to identify the object within the SBML model definition. 209 * Other objects can refer to the component using this identifier. The 210 * data type of 'id' is always <code>SId</code> or a type derived 211 * from that, such as <code>UnitSId</code>, depending on the object in 212 * question. All data types are defined as follows: 213 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 214 * letter .= 'a'..'z','A'..'Z' 215 * digit .= '0'..'9' 216 * idChar .= letter | digit | '_' 217 * SId .= ( letter | '_' ) idChar* 218 * </pre> 219 <p> 220 * The characters <code>(</code> and <code>)</code> are used for grouping, the 221 * character <code>*</code> 'zero or more times', and the character 222 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 223 * determined by an exact character sequence match; i.e., comparisons must be 224 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 225 * <code>SIdRef</code>, and derived types. 226 <p> 227 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 228 * moved to {@link SBase} directly, instead of being defined individually for many 229 * (but not all) objects. Libsbml has for a long time provided functions 230 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 231 * would fail or otherwise return empty strings if executed on any object 232 * for which those attributes were not defined. Now that all {@link SBase} objects 233 * define those attributes, those functions now succeed for any object with 234 * the appropriate level and version. 235 <p> 236 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 237 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 238 * functions (though not the setId() or unsetId() functions) would instead 239 * reference the value of the 'variable' attribute (for the rules and event 240 * assignments) or the 'symbol' attribute (for initial assignments). 241 * The {@link AlgebraicRule} fell into this category as well, though because it 242 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 243 * always return an empty string, and isSetId() would always return <code>false.</code> 244 * For this reason, four new functions are now provided 245 * (getIdAttribute(), setIdAttribute(String), 246 * isSetIdAttribute(), and unsetIdAttribute()) that will always 247 * act on the actual 'id' attribute, regardless of the object's type. The 248 * new functions should be used instead of the old ones unless the old behavior 249 * is somehow necessary. 250 <p> 251 * Regardless of the level and version of the SBML, these functions allow 252 * client applications to use more generalized code in some situations 253 * (for instance, when manipulating objects that are all known to have 254 * identifiers). If the object in question does not posess an 'id' attribute 255 * according to the SBML specification for the Level and Version in use, 256 * libSBML will not allow the identifier to be set, nor will it read or 257 * write 'id' attributes for those objects. 258 <p> 259 * @return the id of this {@link CompartmentType}. 260 <p> 261 * @see #getIdAttribute() 262 * @see #setIdAttribute(String sid) 263 * @see #isSetIdAttribute() 264 * @see #unsetIdAttribute() 265 */ public 266 String getId() { 267 return libsbmlJNI.CompartmentType_getId(swigCPtr, this); 268 } 269 270 271/** 272 * Returns the value of the 'name' attribute of this {@link CompartmentType} object. 273 <p> 274 * <p> 275 * <p> 276 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 277 * moved to {@link SBase} directly, instead of being defined individually for many 278 * (but not all) objects. Libsbml has for a long time provided functions 279 * defined on {@link SBase} itself to get, set, and unset those attributes, which 280 * would fail or otherwise return empty strings if executed on any object 281 * for which those attributes were not defined. Now that all {@link SBase} objects 282 * define those attributes, those functions now succeed for any object with 283 * the appropriate level and version. 284 <p> 285 * The 'name' attribute is 286 * optional and is not intended to be used for cross-referencing purposes 287 * within a model. Its purpose instead is to provide a human-readable 288 * label for the component. The data type of 'name' is the type 289 * <code>string</code> defined in XML Schema. SBML imposes no 290 * restrictions as to the content of 'name' attributes beyond those 291 * restrictions defined by the <code>string</code> type in XML Schema. 292 <p> 293 * The recommended practice for handling 'name' is as follows. If a 294 * software tool has the capability for displaying the content of 'name' 295 * attributes, it should display this content to the user as a 296 * component's label instead of the component's 'id'. If the user 297 * interface does not have this capability (e.g., because it cannot 298 * display or use special characters in symbol names), or if the 'name' 299 * attribute is missing on a given component, then the user interface 300 * should display the value of the 'id' attribute instead. (Script 301 * language interpreters are especially likely to display 'id' instead of 302 * 'name'.) 303 <p> 304 * As a consequence of the above, authors of systems that automatically 305 * generate the values of 'id' attributes should be aware some systems 306 * may display the 'id''s to the user. Authors therefore may wish to 307 * take some care to have their software create 'id' values that are: (a) 308 * reasonably easy for humans to type and read; and (b) likely to be 309 * meaningful, for example by making the 'id' attribute be an abbreviated 310 * form of the name attribute value. 311 <p> 312 * An additional point worth mentioning is although there are 313 * restrictions on the uniqueness of 'id' values, there are no 314 * restrictions on the uniqueness of 'name' values in a model. This 315 * allows software applications leeway in assigning component identifiers. 316 <p> 317 * Regardless of the level and version of the SBML, these functions allow 318 * client applications to use more generalized code in some situations 319 * (for instance, when manipulating objects that are all known to have 320 * names). If the object in question does not posess a 'name' attribute 321 * according to the SBML specification for the Level and Version in use, 322 * libSBML will not allow the name to be set, nor will it read or 323 * write 'name' attributes for those objects. 324 <p> 325 * @return the name of this SBML object, or the empty string if not set or unsettable. 326 <p> 327 * @see #getIdAttribute() 328 * @see #isSetName() 329 * @see #setName(String sid) 330 * @see #unsetName() 331 */ public 332 String getName() { 333 return libsbmlJNI.CompartmentType_getName(swigCPtr, this); 334 } 335 336 337/** 338 * Predicate returning <code>true</code> if this {@link CompartmentType} object's 'id' 339 * attribute is set. 340 <p> 341 * <p> 342 * @note Because of the inconsistent behavior of this function with 343 * respect to assignments and rules, it is now recommended to 344 * use the isSetIdAttribute() function instead. 345 <p> 346 * <p> 347 * The identifier given by an object's 'id' attribute value 348 * is used to identify the object within the SBML model definition. 349 * Other objects can refer to the component using this identifier. The 350 * data type of 'id' is always <code>SId</code> or a type derived 351 * from that, such as <code>UnitSId</code>, depending on the object in 352 * question. All data types are defined as follows: 353 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 354 * letter .= 'a'..'z','A'..'Z' 355 * digit .= '0'..'9' 356 * idChar .= letter | digit | '_' 357 * SId .= ( letter | '_' ) idChar* 358 * </pre> 359 <p> 360 * The characters <code>(</code> and <code>)</code> are used for grouping, the 361 * character <code>*</code> 'zero or more times', and the character 362 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 363 * determined by an exact character sequence match; i.e., comparisons must be 364 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 365 * <code>SIdRef</code>, and derived types. 366 <p> 367 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 368 * moved to {@link SBase} directly, instead of being defined individually for many 369 * (but not all) objects. Libsbml has for a long time provided functions 370 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 371 * would fail or otherwise return empty strings if executed on any object 372 * for which those attributes were not defined. Now that all {@link SBase} objects 373 * define those attributes, those functions now succeed for any object with 374 * the appropriate level and version. 375 <p> 376 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 377 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 378 * functions (though not the setId() or unsetId() functions) would instead 379 * reference the value of the 'variable' attribute (for the rules and event 380 * assignments) or the 'symbol' attribute (for initial assignments). 381 * The {@link AlgebraicRule} fell into this category as well, though because it 382 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 383 * always return an empty string, and isSetId() would always return <code>false.</code> 384 * For this reason, four new functions are now provided 385 * (getIdAttribute(), setIdAttribute(String), 386 * isSetIdAttribute(), and unsetIdAttribute()) that will always 387 * act on the actual 'id' attribute, regardless of the object's type. The 388 * new functions should be used instead of the old ones unless the old behavior 389 * is somehow necessary. 390 <p> 391 * Regardless of the level and version of the SBML, these functions allow 392 * client applications to use more generalized code in some situations 393 * (for instance, when manipulating objects that are all known to have 394 * identifiers). If the object in question does not posess an 'id' attribute 395 * according to the SBML specification for the Level and Version in use, 396 * libSBML will not allow the identifier to be set, nor will it read or 397 * write 'id' attributes for those objects. 398 <p> 399 * @return <code>true</code> if the 'id' attribute of this SBML object is 400 * set, <code>false</code> otherwise. 401 <p> 402 * @see #getIdAttribute() 403 * @see #setIdAttribute(String sid) 404 * @see #unsetIdAttribute() 405 * @see #isSetIdAttribute() 406 */ public 407 boolean isSetId() { 408 return libsbmlJNI.CompartmentType_isSetId(swigCPtr, this); 409 } 410 411 412/** 413 * Predicate returning <code>true</code> if this {@link CompartmentType} object's 'name' 414 * attribute is set. 415 <p> 416 * <p> 417 * <p> 418 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 419 * moved to {@link SBase} directly, instead of being defined individually for many 420 * (but not all) objects. Libsbml has for a long time provided functions 421 * defined on {@link SBase} itself to get, set, and unset those attributes, which 422 * would fail or otherwise return empty strings if executed on any object 423 * for which those attributes were not defined. Now that all {@link SBase} objects 424 * define those attributes, those functions now succeed for any object with 425 * the appropriate level and version. 426 <p> 427 * The 'name' attribute is 428 * optional and is not intended to be used for cross-referencing purposes 429 * within a model. Its purpose instead is to provide a human-readable 430 * label for the component. The data type of 'name' is the type 431 * <code>string</code> defined in XML Schema. SBML imposes no 432 * restrictions as to the content of 'name' attributes beyond those 433 * restrictions defined by the <code>string</code> type in XML Schema. 434 <p> 435 * The recommended practice for handling 'name' is as follows. If a 436 * software tool has the capability for displaying the content of 'name' 437 * attributes, it should display this content to the user as a 438 * component's label instead of the component's 'id'. If the user 439 * interface does not have this capability (e.g., because it cannot 440 * display or use special characters in symbol names), or if the 'name' 441 * attribute is missing on a given component, then the user interface 442 * should display the value of the 'id' attribute instead. (Script 443 * language interpreters are especially likely to display 'id' instead of 444 * 'name'.) 445 <p> 446 * As a consequence of the above, authors of systems that automatically 447 * generate the values of 'id' attributes should be aware some systems 448 * may display the 'id''s to the user. Authors therefore may wish to 449 * take some care to have their software create 'id' values that are: (a) 450 * reasonably easy for humans to type and read; and (b) likely to be 451 * meaningful, for example by making the 'id' attribute be an abbreviated 452 * form of the name attribute value. 453 <p> 454 * An additional point worth mentioning is although there are 455 * restrictions on the uniqueness of 'id' values, there are no 456 * restrictions on the uniqueness of 'name' values in a model. This 457 * allows software applications leeway in assigning component identifiers. 458 <p> 459 * Regardless of the level and version of the SBML, these functions allow 460 * client applications to use more generalized code in some situations 461 * (for instance, when manipulating objects that are all known to have 462 * names). If the object in question does not posess a 'name' attribute 463 * according to the SBML specification for the Level and Version in use, 464 * libSBML will not allow the name to be set, nor will it read or 465 * write 'name' attributes for those objects. 466 <p> 467 * @return <code>true</code> if the 'name' attribute of this SBML object is 468 * set, <code>false</code> otherwise. 469 <p> 470 * @see #getName() 471 * @see #setName(String sid) 472 * @see #unsetName() 473 */ public 474 boolean isSetName() { 475 return libsbmlJNI.CompartmentType_isSetName(swigCPtr, this); 476 } 477 478 479/** 480 * Sets the value of the 'id' attribute of this {@link CompartmentType}. 481 <p> 482 * <p> 483 * The string <code>sid</code> is copied. 484 <p> 485 * <p> 486 * The identifier given by an object's 'id' attribute value 487 * is used to identify the object within the SBML model definition. 488 * Other objects can refer to the component using this identifier. The 489 * data type of 'id' is always <code>SId</code> or a type derived 490 * from that, such as <code>UnitSId</code>, depending on the object in 491 * question. All data types are defined as follows: 492 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 493 * letter .= 'a'..'z','A'..'Z' 494 * digit .= '0'..'9' 495 * idChar .= letter | digit | '_' 496 * SId .= ( letter | '_' ) idChar* 497 * </pre> 498 <p> 499 * The characters <code>(</code> and <code>)</code> are used for grouping, the 500 * character <code>*</code> 'zero or more times', and the character 501 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers is 502 * determined by an exact character sequence match; i.e., comparisons must be 503 * performed in a case-sensitive manner. This applies to all uses of <code>SId</code>, 504 * <code>SIdRef</code>, and derived types. 505 <p> 506 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 507 * moved to {@link SBase} directly, instead of being defined individually for many 508 * (but not all) objects. Libsbml has for a long time provided functions 509 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 510 * would fail or otherwise return empty strings if executed on any object 511 * for which those attributes were not defined. Now that all {@link SBase} objects 512 * define those attributes, those functions now succeed for any object with 513 * the appropriate level and version. 514 <p> 515 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 516 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 517 * functions (though not the setId() or unsetId() functions) would instead 518 * reference the value of the 'variable' attribute (for the rules and event 519 * assignments) or the 'symbol' attribute (for initial assignments). 520 * The {@link AlgebraicRule} fell into this category as well, though because it 521 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 522 * always return an empty string, and isSetId() would always return <code>false.</code> 523 * For this reason, four new functions are now provided 524 * (getIdAttribute(), setIdAttribute(String), 525 * isSetIdAttribute(), and unsetIdAttribute()) that will always 526 * act on the actual 'id' attribute, regardless of the object's type. The 527 * new functions should be used instead of the old ones unless the old behavior 528 * is somehow necessary. 529 <p> 530 * Regardless of the level and version of the SBML, these functions allow 531 * client applications to use more generalized code in some situations 532 * (for instance, when manipulating objects that are all known to have 533 * identifiers). If the object in question does not posess an 'id' attribute 534 * according to the SBML specification for the Level and Version in use, 535 * libSBML will not allow the identifier to be set, nor will it read or 536 * write 'id' attributes for those objects. 537 <p> 538 * @param sid the string to use as the identifier of this object. 539 <p> 540 * <p> 541 * @return integer value indicating success/failure of the 542 * function. The possible values 543 * returned by this function are: 544 * <ul> 545 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 546 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 547 * <li> {@link libsbmlConstants#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE} 548 * 549 * </ul> <p> 550 * @see #getIdAttribute() 551 * @see #setIdAttribute(String sid) 552 * @see #isSetIdAttribute() 553 * @see #unsetIdAttribute() 554 */ public 555 int setId(String sid) { 556 return libsbmlJNI.CompartmentType_setId(swigCPtr, this, sid); 557 } 558 559 560/** 561 * Sets the value of the 'name' attribute of this {@link CompartmentType}. 562 <p> 563 * <p> 564 * The string in <code>name</code> is copied. 565 <p> 566 * @param name the new name for the SBML object. 567 <p> 568 * <p> 569 * @return integer value indicating success/failure of the 570 * function. The possible values 571 * returned by this function are: 572 * <ul> 573 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 574 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE} 575 * 576 * </ul> 577 */ public 578 int setName(String name) { 579 return libsbmlJNI.CompartmentType_setName(swigCPtr, this, name); 580 } 581 582 583/** 584 * Unsets the value of the 'name' attribute of this {@link CompartmentType} object. 585 <p> 586 * <p> 587 * <p> 588 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 589 * moved to {@link SBase} directly, instead of being defined individually for many 590 * (but not all) objects. Libsbml has for a long time provided functions 591 * defined on {@link SBase} itself to get, set, and unset those attributes, which 592 * would fail or otherwise return empty strings if executed on any object 593 * for which those attributes were not defined. Now that all {@link SBase} objects 594 * define those attributes, those functions now succeed for any object with 595 * the appropriate level and version. 596 <p> 597 * The 'name' attribute is 598 * optional and is not intended to be used for cross-referencing purposes 599 * within a model. Its purpose instead is to provide a human-readable 600 * label for the component. The data type of 'name' is the type 601 * <code>string</code> defined in XML Schema. SBML imposes no 602 * restrictions as to the content of 'name' attributes beyond those 603 * restrictions defined by the <code>string</code> type in XML Schema. 604 <p> 605 * The recommended practice for handling 'name' is as follows. If a 606 * software tool has the capability for displaying the content of 'name' 607 * attributes, it should display this content to the user as a 608 * component's label instead of the component's 'id'. If the user 609 * interface does not have this capability (e.g., because it cannot 610 * display or use special characters in symbol names), or if the 'name' 611 * attribute is missing on a given component, then the user interface 612 * should display the value of the 'id' attribute instead. (Script 613 * language interpreters are especially likely to display 'id' instead of 614 * 'name'.) 615 <p> 616 * As a consequence of the above, authors of systems that automatically 617 * generate the values of 'id' attributes should be aware some systems 618 * may display the 'id''s to the user. Authors therefore may wish to 619 * take some care to have their software create 'id' values that are: (a) 620 * reasonably easy for humans to type and read; and (b) likely to be 621 * meaningful, for example by making the 'id' attribute be an abbreviated 622 * form of the name attribute value. 623 <p> 624 * An additional point worth mentioning is although there are 625 * restrictions on the uniqueness of 'id' values, there are no 626 * restrictions on the uniqueness of 'name' values in a model. This 627 * allows software applications leeway in assigning component identifiers. 628 <p> 629 * Regardless of the level and version of the SBML, these functions allow 630 * client applications to use more generalized code in some situations 631 * (for instance, when manipulating objects that are all known to have 632 * names). If the object in question does not posess a 'name' attribute 633 * according to the SBML specification for the Level and Version in use, 634 * libSBML will not allow the name to be set, nor will it read or 635 * write 'name' attributes for those objects. 636 <p> 637 * <p> 638 * @return integer value indicating success/failure of the 639 * function. The possible values 640 * returned by this function are: 641 * <ul> 642 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS} 643 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED} 644 * 645 * </ul> <p> 646 * @see #getName() 647 * @see #setName(String sid) 648 * @see #isSetName() 649 */ public 650 int unsetName() { 651 return libsbmlJNI.CompartmentType_unsetName(swigCPtr, this); 652 } 653 654 655/** 656 * Returns the libSBML type code for this SBML object. 657 <p> 658 * <p> 659 * LibSBML attaches an identifying code to every kind of SBML object. These 660 * are integer constants known as <em>SBML type codes</em>. The names of all 661 * the codes begin with the characters <code>SBML_</code>. 662 * In the Java language interface for libSBML, the 663 * type codes are defined as static integer constants in the interface class 664 * {@link libsbmlConstants}. Note that different Level 3 665 * package plug-ins may use overlapping type codes; to identify the package 666 * to which a given object belongs, call the 667 * <code>{@link SBase#getPackageName()} 668 * </code> 669 * method on the object. 670 <p> 671 * @return the SBML type code for this object: 672 * {@link libsbmlConstants#SBML_COMPARTMENT_TYPE SBML_COMPARTMENT_TYPE} (default). 673 <p> 674 * <p> 675 * @warning <span class='warning'>The specific integer values of the possible 676 * type codes may be reused by different libSBML plug-ins for SBML Level 3. 677 * packages, To fully identify the correct code, <strong>it is necessary to 678 * invoke both getTypeCode() and getPackageName()</strong>.</span> 679 <p> 680 * @see #getElementName() 681 * @see #getPackageName() 682 */ public 683 int getTypeCode() { 684 return libsbmlJNI.CompartmentType_getTypeCode(swigCPtr, this); 685 } 686 687 688/** 689 * Returns the XML element name of this object 690 <p> 691 * For {@link CompartmentType}, the element name is always <code>'compartmentType'.</code> 692 <p> 693 * @return the name of this element. 694 <p> 695 * @see #getTypeCode() 696 * @see #getPackageName() 697 */ public 698 String getElementName() { 699 return libsbmlJNI.CompartmentType_getElementName(swigCPtr, this); 700 } 701 702 703/** 704 * Predicate returning <code>true</code> if all the required attributes for this 705 * {@link CompartmentType} object have been set. 706 <p> 707 * The required attributes for a {@link CompartmentType} object are: 708 * <ul> 709 * <li> 'id' 710 * 711 * </ul> <p> 712 * @return <code>true</code> if the required attributes have been set, <code>false</code> 713 * otherwise. 714 */ public 715 boolean hasRequiredAttributes() { 716 return libsbmlJNI.CompartmentType_hasRequiredAttributes(swigCPtr, this); 717 } 718 719}