1 using System; 2 using System.Runtime.InteropServices; 3 4 //------------------------------------------------------------------------------ 5 // <auto-generated /> 6 // 7 // This file was automatically generated by SWIG (http://www.swig.org). 8 // Version 4.0.2 9 // 10 // Do not make changes to this file unless you know what you are doing--modify 11 // the SWIG interface file instead. 12 //------------------------------------------------------------------------------ 13 14 namespace libsbmlcs { 15 16 using System; 17 using System.Runtime.InteropServices; 18 19 /** 20 * @sbmlpackage{core} 21 * 22 @htmlinclude pkg-marker-core.html A <em>compartment type</em> in SBML Level 2. 23 * 24 * SBML Level 2 Versions 2–4 provide the <em>compartment 25 * type</em> as a grouping construct that can be used to establish a 26 * relationship between multiple Compartment objects. A CompartmentType 27 * object only has an identity, and this identity can only be used to 28 * indicate that particular Compartment objects in the model belong to this 29 * type. This may be useful for conveying a modeling intention, such as 30 * when a model contains many similar compartments, either by their 31 * biological function or the reactions they carry. Without a compartment 32 * type construct, it would be impossible within SBML itself to indicate 33 * that all of the compartments share an underlying conceptual relationship 34 * because each SBML compartment must be given a unique and separate 35 * identity. A CompartmentType has no mathematical meaning in 36 * SBML---it has no effect on a model's mathematical interpretation. 37 * Simulators and other numerical analysis software may ignore 38 * CompartmentType definitions and references to them in a model. 39 * 40 * There is no mechanism in SBML Level 2 for representing hierarchies of 41 * compartment types. One CompartmentType instance cannot be the subtype 42 * of another CompartmentType instance; SBML provides no means of defining 43 * such relationships. 44 * 45 * As with other major structures in SBML, CompartmentType has a mandatory 46 * attribute, 'id', used to give the compartment type an identifier. The 47 * identifier must be a text %string conforming to the identifer syntax 48 * permitted in SBML. CompartmentType also has an optional 'name' 49 * attribute, of type @c string. The 'id' and 'name' must be used 50 * according to the guidelines described in the SBML specification (e.g., 51 * Section 3.3 in the Level 2 Version 4 specification). 52 * 53 * CompartmentType was introduced in SBML Level 2 Version 2. It is not 54 * available in SBML Level 1 nor in Level 3. 55 * 56 * @see Compartment 57 * @see ListOfCompartmentTypes 58 * @see SpeciesType 59 * @see ListOfSpeciesTypes 60 * 61 * 62 * 63 */ 64 65 public class CompartmentType : SBase { 66 private HandleRef swigCPtr; 67 CompartmentType(IntPtr cPtr, bool cMemoryOwn)68 internal CompartmentType(IntPtr cPtr, bool cMemoryOwn) : base(libsbmlPINVOKE.CompartmentType_SWIGUpcast(cPtr), cMemoryOwn) 69 { 70 //super(libsbmlPINVOKE.CompartmentTypeUpcast(cPtr), cMemoryOwn); 71 swigCPtr = new HandleRef(this, cPtr); 72 } 73 getCPtr(CompartmentType obj)74 internal static HandleRef getCPtr(CompartmentType obj) 75 { 76 return (obj == null) ? new HandleRef(null, IntPtr.Zero) : obj.swigCPtr; 77 } 78 getCPtrAndDisown(CompartmentType obj)79 internal static HandleRef getCPtrAndDisown (CompartmentType obj) 80 { 81 HandleRef ptr = new HandleRef(null, IntPtr.Zero); 82 83 if (obj != null) 84 { 85 ptr = obj.swigCPtr; 86 obj.swigCMemOwn = false; 87 } 88 89 return ptr; 90 } 91 Dispose(bool disposing)92 protected override void Dispose(bool disposing) { 93 lock(this) { 94 if (swigCPtr.Handle != global::System.IntPtr.Zero) { 95 if (swigCMemOwn) { 96 swigCMemOwn = false; 97 libsbmlPINVOKE.delete_CompartmentType(swigCPtr); 98 } 99 swigCPtr = new global::System.Runtime.InteropServices.HandleRef(null, global::System.IntPtr.Zero); 100 } 101 base.Dispose(disposing); 102 } 103 } 104 105 106 /** 107 * Creates a new CompartmentType object using the given SBML @p level and 108 * @p version values. 109 * 110 * @param level a long integer, the SBML Level to assign to this 111 * CompartmentType. 112 * 113 * @param version a long integer, the SBML Version to assign to this 114 * CompartmentType. 115 * 116 * 117 * @throws SBMLConstructorException 118 * Thrown if the given @p level and @p version combination are invalid 119 * or if this object is incompatible with the given level and version. 120 * 121 * 122 * 123 * 124 * @note Attempting to add an object to an SBMLDocument having a different 125 * combination of SBML Level, Version and XML namespaces than the object 126 * itself will result in an error at the time a caller attempts to make the 127 * addition. A parent object must have compatible Level, Version and XML 128 * namespaces. (Strictly speaking, a parent may also have more XML 129 * namespaces than a child, but the reverse is not permitted.) The 130 * restriction is necessary to ensure that an SBML model has a consistent 131 * overall structure. This requires callers to manage their objects 132 * carefully, but the benefit is increased flexibility in how models can be 133 * created by permitting callers to create objects bottom-up if desired. In 134 * situations where objects are not yet attached to parents (e.g., 135 * SBMLDocument), knowledge of the intented SBML Level and Version help 136 * libSBML determine such things as whether it is valid to assign a 137 * particular value to an attribute. 138 * 139 * 140 */ public CompartmentType(long level, long version)141 CompartmentType(long level, long version) : this(libsbmlPINVOKE.new_CompartmentType__SWIG_0(level, version), true) { 142 if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve(); 143 } 144 145 146 /** 147 * Creates a new CompartmentType object using the given SBMLNamespaces 148 * object @p sbmlns. 149 * 150 * 151 * 152 * The SBMLNamespaces object encapsulates SBML Level/Version/namespaces 153 * information. It is used to communicate the SBML Level, Version, and (in 154 * Level 3) packages used in addition to SBML Level 3 Core. A 155 * common approach to using libSBML's SBMLNamespaces facilities is to create an 156 * SBMLNamespaces object somewhere in a program once, then hand that object 157 * as needed to object constructors that accept SBMLNamespaces as arguments. 158 * 159 * 160 * 161 * It is worth emphasizing that although this constructor does not take an 162 * identifier argument, in SBML Level 2 and beyond, the 'id' 163 * (identifier) attribute of a CompartmentType object is required to have a 164 * value. Thus, callers are cautioned to assign a value after calling this 165 * constructor. Setting the identifier can be accomplished using the 166 * method setId(@if java String@endif). 167 * 168 * @param sbmlns an SBMLNamespaces object. 169 * 170 * 171 * @throws SBMLConstructorException 172 * Thrown if the given @p sbmlns is inconsistent or incompatible 173 * with this object. 174 * 175 * 176 * 177 * 178 * @note Attempting to add an object to an SBMLDocument having a different 179 * combination of SBML Level, Version and XML namespaces than the object 180 * itself will result in an error at the time a caller attempts to make the 181 * addition. A parent object must have compatible Level, Version and XML 182 * namespaces. (Strictly speaking, a parent may also have more XML 183 * namespaces than a child, but the reverse is not permitted.) The 184 * restriction is necessary to ensure that an SBML model has a consistent 185 * overall structure. This requires callers to manage their objects 186 * carefully, but the benefit is increased flexibility in how models can be 187 * created by permitting callers to create objects bottom-up if desired. In 188 * situations where objects are not yet attached to parents (e.g., 189 * SBMLDocument), knowledge of the intented SBML Level and Version help 190 * libSBML determine such things as whether it is valid to assign a 191 * particular value to an attribute. 192 * 193 * 194 */ public CompartmentType(SBMLNamespaces sbmlns)195 CompartmentType(SBMLNamespaces sbmlns) : this(libsbmlPINVOKE.new_CompartmentType__SWIG_1(SBMLNamespaces.getCPtr(sbmlns)), true) { 196 if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve(); 197 } 198 199 200 /** 201 * Copy constructor; creates a copy of this CompartmentType object. 202 * 203 * @param orig the object to copy. 204 */ public CompartmentType(CompartmentType orig)205 CompartmentType(CompartmentType orig) : this(libsbmlPINVOKE.new_CompartmentType__SWIG_2(CompartmentType.getCPtr(orig)), true) { 206 if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve(); 207 } 208 209 210 /** 211 * Creates and returns a deep copy of this CompartmentType object. 212 * 213 * @return the (deep) copy of this CompartmentType object. 214 */ public new clone()215 CompartmentType clone() { 216 global::System.IntPtr cPtr = libsbmlPINVOKE.CompartmentType_clone(swigCPtr); 217 CompartmentType ret = (cPtr == global::System.IntPtr.Zero) ? null : new CompartmentType(cPtr, true); 218 return ret; 219 } 220 221 222 /** 223 * Returns the value of the 'id' attribute of this CompartmentType. 224 * 225 * @note Because of the inconsistent behavior of this function with 226 * respect to assignments and rules, it is now recommended to 227 * use the getIdAttribute() function instead. 228 * 229 * 230 * 231 * The identifier given by an object's 'id' attribute value 232 * is used to identify the object within the SBML model definition. 233 * Other objects can refer to the component using this identifier. The 234 * data type of 'id' is always <code>SId</code> or a type derived 235 * from that, such as <code>UnitSId</code>, depending on the object in 236 * question. All data types are defined as follows: 237 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 238 * letter ::= 'a'..'z','A'..'Z' 239 * digit ::= '0'..'9' 240 * idChar ::= letter | digit | '_' 241 * SId ::= ( letter | '_' ) idChar* 242 * </pre> 243 * The characters <code>(</code> and <code>)</code> are used for grouping, 244 * the character <code>*</code> 'zero or more times', and the character 245 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers 246 * is determined by an exact character sequence match; i.e., comparisons must 247 * be performed in a case-sensitive manner. This applies to all uses of 248 * <code>SId</code>, <code>SIdRef</code>, and derived types. 249 * 250 * Users need to be aware of some important API issues that are the result of 251 * the history of SBML and libSBML. Prior to SBML Level 3 252 * Version 2, SBML defined 'id' and 'name' attributes on only a subset 253 * of SBML objects. To simplify the work of programmers, libSBML's API 254 * provided get, set, check, and unset on the SBase object class itself 255 * instead of on individual subobject classes. This made the 256 * get/set/etc. methods uniformly available on all objects in the libSBML 257 * API. LibSBML simply returned empty strings or otherwise did not act when 258 * the methods were applied to SBML objects that were not defined by the SBML 259 * specification to have 'id' or 'name' attributes. Additional complications 260 * arose with the rule and assignment objects: InitialAssignment, 261 * EventAssignment, AssignmentRule, and RateRule. In early versions of SBML, 262 * the rule object hierarchy was different, and in addition, then as now, 263 * they possess different attributes: 'variable' (for the rules and event 264 * assignments), 'symbol' (for initial assignments), or neither (for 265 * algebraic rules). Prior to SBML Level 3 Version 2, getId() 266 * would always return an empty string, and isSetId() would always return @c 267 * false for objects of these classes. 268 * 269 * With the addition of 'id' and 'name' attributes on SBase in Level 3 270 * Version 2, it became necessary to introduce a new way to interact 271 * with the attributes more consistently in libSBML to avoid breaking 272 * backward compatibility in the behavior of the original 'id' methods. For 273 * this reason, libSBML provides four functions (getIdAttribute(), 274 * setIdAttribute(@if java String@endif), isSetIdAttribute(), and 275 * unsetIdAttribute()) that always act on the actual 'id' attribute inherited 276 * from SBase, regardless of the object's type. <strong>These new methods 277 * should be used instead of the older getId()/setId()/etc. methods</strong> 278 * unless the old behavior is somehow necessary. Regardless of the Level and 279 * Version of the SBML, these functions allow client applications to use more 280 * generalized code in some situations (for instance, when manipulating 281 * objects that are all known to have identifiers). If the object in 282 * question does not posess an 'id' attribute according to the SBML 283 * specification for the Level and Version in use, libSBML will not allow the 284 * identifier to be set, nor will it read or write 'id' attributes for those 285 * objects. 286 * 287 * 288 * 289 * @return the id of this CompartmentType. 290 * 291 * @see getIdAttribute() 292 * @see setIdAttribute(string sid) 293 * @see isSetIdAttribute() 294 * @see unsetIdAttribute() 295 */ public new getId()296 string getId() { 297 string ret = libsbmlPINVOKE.CompartmentType_getId(swigCPtr); 298 return ret; 299 } 300 301 302 /** 303 * Returns the value of the 'name' attribute of this CompartmentType object. 304 * 305 * 306 * 307 * 308 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 309 * moved to SBase directly, instead of being defined individually for many 310 * (but not all) objects. LibSBML has for a long time provided functions 311 * defined on SBase itself to get, set, and unset those attributes, which 312 * would fail or otherwise return empty strings if executed on any object 313 * for which those attributes were not defined. Now that all SBase objects 314 * define those attributes, those functions now succeed for any object with 315 * the appropriate level and version. 316 * 317 * The 'name' attribute is 318 * optional and is not intended to be used for cross-referencing purposes 319 * within a model. Its purpose instead is to provide a human-readable 320 * label for the component. The data type of 'name' is the type 321 * <code>string</code> defined in XML Schema. SBML imposes no 322 * restrictions as to the content of 'name' attributes beyond those 323 * restrictions defined by the <code>string</code> type in XML Schema. 324 * 325 * The recommended practice for handling 'name' is as follows. If a 326 * software tool has the capability for displaying the content of 'name' 327 * attributes, it should display this content to the user as a 328 * component's label instead of the component's 'id'. If the user 329 * interface does not have this capability (e.g., because it cannot 330 * display or use special characters in symbol names), or if the 'name' 331 * attribute is missing on a given component, then the user interface 332 * should display the value of the 'id' attribute instead. (Script 333 * language interpreters are especially likely to display 'id' instead of 334 * 'name'.) 335 * 336 * As a consequence of the above, authors of systems that automatically 337 * generate the values of 'id' attributes should be aware some systems 338 * may display the 'id''s to the user. Authors therefore may wish to 339 * take some care to have their software create 'id' values that are: (a) 340 * reasonably easy for humans to type and read; and (b) likely to be 341 * meaningful, for example by making the 'id' attribute be an abbreviated 342 * form of the name attribute value. 343 * 344 * An additional point worth mentioning is although there are 345 * restrictions on the uniqueness of 'id' values, there are no 346 * restrictions on the uniqueness of 'name' values in a model. This 347 * allows software applications leeway in assigning component identifiers. 348 * 349 * Regardless of the level and version of the SBML, these functions allow 350 * client applications to use more generalized code in some situations 351 * (for instance, when manipulating objects that are all known to have 352 * names). If the object in question does not posess a 'name' attribute 353 * according to the SBML specification for the Level and Version in use, 354 * libSBML will not allow the name to be set, nor will it read or 355 * write 'name' attributes for those objects. 356 * 357 * 358 * 359 * @return the name of this SBML object, or the empty string if not set or unsettable. 360 * 361 * @see getIdAttribute() 362 * @see isSetName() 363 * @see setName(string sid) 364 * @see unsetName() 365 * 366 * 367 */ public new getName()368 string getName() { 369 string ret = libsbmlPINVOKE.CompartmentType_getName(swigCPtr); 370 return ret; 371 } 372 373 374 /** 375 * Predicate returning @c true if this CompartmentType object's 'id' 376 * attribute is set. 377 * 378 * 379 * 380 * 381 * The identifier given by an object's 'id' attribute value 382 * is used to identify the object within the SBML model definition. 383 * Other objects can refer to the component using this identifier. The 384 * data type of 'id' is always <code>SId</code> or a type derived 385 * from that, such as <code>UnitSId</code>, depending on the object in 386 * question. All data types are defined as follows: 387 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 388 * letter ::= 'a'..'z','A'..'Z' 389 * digit ::= '0'..'9' 390 * idChar ::= letter | digit | '_' 391 * SId ::= ( letter | '_' ) idChar* 392 * </pre> 393 * The characters <code>(</code> and <code>)</code> are used for grouping, 394 * the character <code>*</code> 'zero or more times', and the character 395 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers 396 * is determined by an exact character sequence match; i.e., comparisons must 397 * be performed in a case-sensitive manner. This applies to all uses of 398 * <code>SId</code>, <code>SIdRef</code>, and derived types. 399 * 400 * Users need to be aware of some important API issues that are the result of 401 * the history of SBML and libSBML. Prior to SBML Level 3 402 * Version 2, SBML defined 'id' and 'name' attributes on only a subset 403 * of SBML objects. To simplify the work of programmers, libSBML's API 404 * provided get, set, check, and unset on the SBase object class itself 405 * instead of on individual subobject classes. This made the 406 * get/set/etc. methods uniformly available on all objects in the libSBML 407 * API. LibSBML simply returned empty strings or otherwise did not act when 408 * the methods were applied to SBML objects that were not defined by the SBML 409 * specification to have 'id' or 'name' attributes. Additional complications 410 * arose with the rule and assignment objects: InitialAssignment, 411 * EventAssignment, AssignmentRule, and RateRule. In early versions of SBML, 412 * the rule object hierarchy was different, and in addition, then as now, 413 * they possess different attributes: 'variable' (for the rules and event 414 * assignments), 'symbol' (for initial assignments), or neither (for 415 * algebraic rules). Prior to SBML Level 3 Version 2, getId() 416 * would always return an empty string, and isSetId() would always return @c 417 * false for objects of these classes. 418 * 419 * With the addition of 'id' and 'name' attributes on SBase in Level 3 420 * Version 2, it became necessary to introduce a new way to interact 421 * with the attributes more consistently in libSBML to avoid breaking 422 * backward compatibility in the behavior of the original 'id' methods. For 423 * this reason, libSBML provides four functions (getIdAttribute(), 424 * setIdAttribute(@if java String@endif), isSetIdAttribute(), and 425 * unsetIdAttribute()) that always act on the actual 'id' attribute inherited 426 * from SBase, regardless of the object's type. <strong>These new methods 427 * should be used instead of the older getId()/setId()/etc. methods</strong> 428 * unless the old behavior is somehow necessary. Regardless of the Level and 429 * Version of the SBML, these functions allow client applications to use more 430 * generalized code in some situations (for instance, when manipulating 431 * objects that are all known to have identifiers). If the object in 432 * question does not posess an 'id' attribute according to the SBML 433 * specification for the Level and Version in use, libSBML will not allow the 434 * identifier to be set, nor will it read or write 'id' attributes for those 435 * objects. 436 * 437 * 438 * 439 * @return @c true if the 'id' attribute of this SBML object is 440 * set, @c false otherwise. 441 * 442 * @note Because of the inconsistent behavior of this function with 443 * respect to assignments and rules, it is recommended that callers 444 * use isSetIdAttribute() instead. 445 * 446 * @see getIdAttribute() 447 * @see setIdAttribute(string sid) 448 * @see unsetIdAttribute() 449 * @see isSetIdAttribute() 450 * 451 * 452 */ public new isSetId()453 bool isSetId() { 454 bool ret = libsbmlPINVOKE.CompartmentType_isSetId(swigCPtr); 455 return ret; 456 } 457 458 459 /** 460 * Predicate returning @c true if this CompartmentType object's 'name' 461 * attribute is set. 462 * 463 * 464 * 465 * 466 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 467 * moved to SBase directly, instead of being defined individually for many 468 * (but not all) objects. LibSBML has for a long time provided functions 469 * defined on SBase itself to get, set, and unset those attributes, which 470 * would fail or otherwise return empty strings if executed on any object 471 * for which those attributes were not defined. Now that all SBase objects 472 * define those attributes, those functions now succeed for any object with 473 * the appropriate level and version. 474 * 475 * The 'name' attribute is 476 * optional and is not intended to be used for cross-referencing purposes 477 * within a model. Its purpose instead is to provide a human-readable 478 * label for the component. The data type of 'name' is the type 479 * <code>string</code> defined in XML Schema. SBML imposes no 480 * restrictions as to the content of 'name' attributes beyond those 481 * restrictions defined by the <code>string</code> type in XML Schema. 482 * 483 * The recommended practice for handling 'name' is as follows. If a 484 * software tool has the capability for displaying the content of 'name' 485 * attributes, it should display this content to the user as a 486 * component's label instead of the component's 'id'. If the user 487 * interface does not have this capability (e.g., because it cannot 488 * display or use special characters in symbol names), or if the 'name' 489 * attribute is missing on a given component, then the user interface 490 * should display the value of the 'id' attribute instead. (Script 491 * language interpreters are especially likely to display 'id' instead of 492 * 'name'.) 493 * 494 * As a consequence of the above, authors of systems that automatically 495 * generate the values of 'id' attributes should be aware some systems 496 * may display the 'id''s to the user. Authors therefore may wish to 497 * take some care to have their software create 'id' values that are: (a) 498 * reasonably easy for humans to type and read; and (b) likely to be 499 * meaningful, for example by making the 'id' attribute be an abbreviated 500 * form of the name attribute value. 501 * 502 * An additional point worth mentioning is although there are 503 * restrictions on the uniqueness of 'id' values, there are no 504 * restrictions on the uniqueness of 'name' values in a model. This 505 * allows software applications leeway in assigning component identifiers. 506 * 507 * Regardless of the level and version of the SBML, these functions allow 508 * client applications to use more generalized code in some situations 509 * (for instance, when manipulating objects that are all known to have 510 * names). If the object in question does not posess a 'name' attribute 511 * according to the SBML specification for the Level and Version in use, 512 * libSBML will not allow the name to be set, nor will it read or 513 * write 'name' attributes for those objects. 514 * 515 * 516 * 517 * @return @c true if the 'name' attribute of this SBML object is 518 * set, @c false otherwise. 519 * 520 * @see getName() 521 * @see setName(string sid) 522 * @see unsetName() 523 * 524 * 525 */ public new isSetName()526 bool isSetName() { 527 bool ret = libsbmlPINVOKE.CompartmentType_isSetName(swigCPtr); 528 return ret; 529 } 530 531 532 /** 533 * Sets the value of the 'id' attribute of this CompartmentType. 534 * 535 * 536 * 537 * The string @p sid is copied. 538 * 539 * 540 * 541 * The identifier given by an object's 'id' attribute value 542 * is used to identify the object within the SBML model definition. 543 * Other objects can refer to the component using this identifier. The 544 * data type of 'id' is always <code>SId</code> or a type derived 545 * from that, such as <code>UnitSId</code>, depending on the object in 546 * question. All data types are defined as follows: 547 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 548 * letter ::= 'a'..'z','A'..'Z' 549 * digit ::= '0'..'9' 550 * idChar ::= letter | digit | '_' 551 * SId ::= ( letter | '_' ) idChar* 552 * </pre> 553 * The characters <code>(</code> and <code>)</code> are used for grouping, 554 * the character <code>*</code> 'zero or more times', and the character 555 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers 556 * is determined by an exact character sequence match; i.e., comparisons must 557 * be performed in a case-sensitive manner. This applies to all uses of 558 * <code>SId</code>, <code>SIdRef</code>, and derived types. 559 * 560 * Users need to be aware of some important API issues that are the result of 561 * the history of SBML and libSBML. Prior to SBML Level 3 562 * Version 2, SBML defined 'id' and 'name' attributes on only a subset 563 * of SBML objects. To simplify the work of programmers, libSBML's API 564 * provided get, set, check, and unset on the SBase object class itself 565 * instead of on individual subobject classes. This made the 566 * get/set/etc. methods uniformly available on all objects in the libSBML 567 * API. LibSBML simply returned empty strings or otherwise did not act when 568 * the methods were applied to SBML objects that were not defined by the SBML 569 * specification to have 'id' or 'name' attributes. Additional complications 570 * arose with the rule and assignment objects: InitialAssignment, 571 * EventAssignment, AssignmentRule, and RateRule. In early versions of SBML, 572 * the rule object hierarchy was different, and in addition, then as now, 573 * they possess different attributes: 'variable' (for the rules and event 574 * assignments), 'symbol' (for initial assignments), or neither (for 575 * algebraic rules). Prior to SBML Level 3 Version 2, getId() 576 * would always return an empty string, and isSetId() would always return @c 577 * false for objects of these classes. 578 * 579 * With the addition of 'id' and 'name' attributes on SBase in Level 3 580 * Version 2, it became necessary to introduce a new way to interact 581 * with the attributes more consistently in libSBML to avoid breaking 582 * backward compatibility in the behavior of the original 'id' methods. For 583 * this reason, libSBML provides four functions (getIdAttribute(), 584 * setIdAttribute(@if java String@endif), isSetIdAttribute(), and 585 * unsetIdAttribute()) that always act on the actual 'id' attribute inherited 586 * from SBase, regardless of the object's type. <strong>These new methods 587 * should be used instead of the older getId()/setId()/etc. methods</strong> 588 * unless the old behavior is somehow necessary. Regardless of the Level and 589 * Version of the SBML, these functions allow client applications to use more 590 * generalized code in some situations (for instance, when manipulating 591 * objects that are all known to have identifiers). If the object in 592 * question does not posess an 'id' attribute according to the SBML 593 * specification for the Level and Version in use, libSBML will not allow the 594 * identifier to be set, nor will it read or write 'id' attributes for those 595 * objects. 596 * 597 * 598 * 599 * @param sid the string to use as the identifier of this object. 600 * 601 * 602 * @return integer value indicating success/failure of the 603 * function. @if clike The value is drawn from the 604 * enumeration #OperationReturnValues_t. @endif The possible values 605 * returned by this function are: 606 * @li @link libsbml#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS@endlink 607 * @li @link libsbml#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE@endlink 608 * @li @link libsbml#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE@endlink 609 * 610 * @see getIdAttribute() 611 * @see setIdAttribute(string sid) 612 * @see isSetIdAttribute() 613 * @see unsetIdAttribute() 614 * 615 * 616 */ public new setId(string sid)617 int setId(string sid) { 618 int ret = libsbmlPINVOKE.CompartmentType_setId(swigCPtr, sid); 619 if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve(); 620 return ret; 621 } 622 623 624 /** 625 * Sets the value of the 'name' attribute of this CompartmentType. 626 * 627 * 628 * 629 * 630 * The string in @p name is copied. 631 * 632 * @param name the new name for the SBML object. 633 * 634 * 635 * @return integer value indicating success/failure of the 636 * function. @if clike The value is drawn from the 637 * enumeration #OperationReturnValues_t. @endif The possible values 638 * returned by this function are: 639 * @li @link libsbml#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS@endlink 640 * @li @link libsbml#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE@endlink 641 * 642 * 643 */ public new setName(string name)644 int setName(string name) { 645 int ret = libsbmlPINVOKE.CompartmentType_setName(swigCPtr, name); 646 if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve(); 647 return ret; 648 } 649 650 651 /** 652 * Unsets the value of the 'name' attribute of this CompartmentType object. 653 * 654 * 655 * 656 * 657 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 658 * moved to SBase directly, instead of being defined individually for many 659 * (but not all) objects. LibSBML has for a long time provided functions 660 * defined on SBase itself to get, set, and unset those attributes, which 661 * would fail or otherwise return empty strings if executed on any object 662 * for which those attributes were not defined. Now that all SBase objects 663 * define those attributes, those functions now succeed for any object with 664 * the appropriate level and version. 665 * 666 * The 'name' attribute is 667 * optional and is not intended to be used for cross-referencing purposes 668 * within a model. Its purpose instead is to provide a human-readable 669 * label for the component. The data type of 'name' is the type 670 * <code>string</code> defined in XML Schema. SBML imposes no 671 * restrictions as to the content of 'name' attributes beyond those 672 * restrictions defined by the <code>string</code> type in XML Schema. 673 * 674 * The recommended practice for handling 'name' is as follows. If a 675 * software tool has the capability for displaying the content of 'name' 676 * attributes, it should display this content to the user as a 677 * component's label instead of the component's 'id'. If the user 678 * interface does not have this capability (e.g., because it cannot 679 * display or use special characters in symbol names), or if the 'name' 680 * attribute is missing on a given component, then the user interface 681 * should display the value of the 'id' attribute instead. (Script 682 * language interpreters are especially likely to display 'id' instead of 683 * 'name'.) 684 * 685 * As a consequence of the above, authors of systems that automatically 686 * generate the values of 'id' attributes should be aware some systems 687 * may display the 'id''s to the user. Authors therefore may wish to 688 * take some care to have their software create 'id' values that are: (a) 689 * reasonably easy for humans to type and read; and (b) likely to be 690 * meaningful, for example by making the 'id' attribute be an abbreviated 691 * form of the name attribute value. 692 * 693 * An additional point worth mentioning is although there are 694 * restrictions on the uniqueness of 'id' values, there are no 695 * restrictions on the uniqueness of 'name' values in a model. This 696 * allows software applications leeway in assigning component identifiers. 697 * 698 * Regardless of the level and version of the SBML, these functions allow 699 * client applications to use more generalized code in some situations 700 * (for instance, when manipulating objects that are all known to have 701 * names). If the object in question does not posess a 'name' attribute 702 * according to the SBML specification for the Level and Version in use, 703 * libSBML will not allow the name to be set, nor will it read or 704 * write 'name' attributes for those objects. 705 * 706 * 707 * 708 * 709 * @return integer value indicating success/failure of the 710 * function. @if clike The value is drawn from the 711 * enumeration #OperationReturnValues_t. @endif The possible values 712 * returned by this function are: 713 * @li @link libsbml#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS@endlink 714 * @li @link libsbml#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED@endlink 715 * 716 * @see getName() 717 * @see setName(string sid) 718 * @see isSetName() 719 * 720 * 721 */ public new unsetName()722 int unsetName() { 723 int ret = libsbmlPINVOKE.CompartmentType_unsetName(swigCPtr); 724 return ret; 725 } 726 727 728 /** 729 * Returns the libSBML type code for this SBML object. 730 * 731 * 732 * 733 * LibSBML attaches an identifying code to every kind of SBML object. These 734 * are integer constants known as <em>SBML type codes</em>. The names of all 735 * the codes begin with the characters <code>SBML_</code>. 736 * @if clike The set of possible type codes for core elements is defined in 737 * the enumeration #SBMLTypeCode_t, and in addition, libSBML plug-ins for 738 * SBML Level 3 packages define their own extra enumerations of type 739 * codes (e.g., #SBMLLayoutTypeCode_t for the Level 3 Layout 740 * package).@endif@if java In the Java language interface for libSBML, the 741 * type codes are defined as static integer constants in the interface class 742 * {@link libsbmlConstants}. @endif@if python In the Python language 743 * interface for libSBML, the type codes are defined as static integer 744 * constants in the interface class @link libsbml@endlink.@endif@if csharp In 745 * the C# language interface for libSBML, the type codes are defined as 746 * static integer constants in the interface class 747 * @link libsbmlcs.libsbml@endlink.@endif Note that different Level 3 748 * package plug-ins may use overlapping type codes; to identify the package 749 * to which a given object belongs, call the 750 * <code>@if conly SBase_getPackageName() 751 * @else SBase::getPackageName() 752 * @endif</code> 753 * method on the object. 754 * 755 * The exception to this is lists: all SBML-style list elements have the type 756 * @link libsbml#SBML_LIST_OF SBML_LIST_OF@endlink, regardless of what package they 757 * are from. 758 * 759 * 760 * 761 * @return the SBML type code for this object: 762 * @link libsbml#SBML_COMPARTMENT_TYPE SBML_COMPARTMENT_TYPE@endlink (default). 763 * 764 * 765 * @warning <span class='warning'>The specific integer values of the possible 766 * type codes may be reused by different libSBML plug-ins for SBML Level 3. 767 * packages, To fully identify the correct code, <strong>it is necessary to 768 * invoke both getPackageName() and getTypeCode()</strong> (or 769 * ListOf::getItemTypeCode()).</span> 770 * 771 * 772 * 773 * @see getElementName() 774 * @see getPackageName() 775 */ public new getTypeCode()776 int getTypeCode() { 777 int ret = libsbmlPINVOKE.CompartmentType_getTypeCode(swigCPtr); 778 return ret; 779 } 780 781 782 /** 783 * Returns the XML element name of this object 784 * 785 * For CompartmentType, the element name is always @c 'compartmentType'. 786 * 787 * @return the name of this element. 788 * 789 * @see getTypeCode() 790 * @see getPackageName() 791 */ public new getElementName()792 string getElementName() { 793 string ret = libsbmlPINVOKE.CompartmentType_getElementName(swigCPtr); 794 return ret; 795 } 796 797 798 /** 799 * Predicate returning @c true if all the required attributes for this 800 * CompartmentType object have been set. 801 * 802 * The required attributes for a CompartmentType object are: 803 * @li 'id' 804 * 805 * @return @c true if the required attributes have been set, @c false 806 * otherwise. 807 */ public new hasRequiredAttributes()808 bool hasRequiredAttributes() { 809 bool ret = libsbmlPINVOKE.CompartmentType_hasRequiredAttributes(swigCPtr); 810 return ret; 811 } 812 813 } 814 815 } 816