1 //------------------------------------------------------------------------------ 2 // <auto-generated /> 3 // 4 // This file was automatically generated by SWIG (http://www.swig.org). 5 // Version 4.0.2 6 // 7 // Do not make changes to this file unless you know what you are doing--modify 8 // the SWIG interface file instead. 9 //------------------------------------------------------------------------------ 10 11 namespace libsbml { 12 13 using System; 14 using System.Runtime.InteropServices; 15 16 /** 17 * @sbmlpackage{core} 18 * 19 @htmlinclude pkg-marker-core.html A user-defined function in an SBML model. 20 * 21 * The FunctionDefinition structure associates an identifier with a 22 * function definition. This identifier can then be used as the function 23 * called in subsequent MathML content elsewhere in an SBML model. 24 * 25 * FunctionDefinition has one required attribute, 'id', to give the 26 * function a unique identifier by which other parts of an SBML model 27 * definition can refer to it. A FunctionDefinition instance can also have 28 * an optional 'name' attribute of type @c string. Identifiers and names 29 * must be used according to the guidelines described in the %SBML 30 * specification (e.g., Section 3.3 in the Level 2 Version 4 31 * specification). 32 * 33 * FunctionDefinition has a 'math' subelement containing a MathML 34 * expression defining the function body. In SBML Level 2 and SBML 35 * Level 3 Version 1, that 'math' subelement is required; 36 * in SBML Level 3 Version 2, this restriction was relaxed, 37 * making the 'math' subelement optional. The content of this element can 38 * only be a MathML 'lambda' element. The 'lambda' element must begin with 39 * zero or more 'bvar' elements, followed by any other of the elements in 40 * the MathML subset allowed in SBML Level 2 @em except 'lambda' (i.e., a 41 * 'lambda' element cannot contain another 'lambda' element). This is the 42 * only place in SBML where a 'lambda' element can be used. The function 43 * defined by a FunctionDefinition is only available for use in other 44 * MathML elements that @em follow the FunctionDefinition definition in the 45 * model. (These restrictions prevent recursive and mutually-recursive 46 * functions from being expressed.) 47 * 48 * A further restriction on the content of 'math' is that it cannot contain 49 * references to variables other than the variables declared to the 50 * 'lambda' itself. That is, the contents of MathML 'ci' elements inside 51 * the body of the 'lambda' can only be the variables declared by its 52 * 'bvar' elements, or the identifiers of other FunctionDefinition 53 * instances in the model. This means must be written so that all 54 * variables or parameters used in the MathML content are passed to them 55 * via their function parameters. In SBML Level 2, this restriction 56 * applies also to the MathML @c csymbol elements for @em time and @em 57 * delay; in SBML Level 3, it additionally applies to the @c csymbol 58 * element for @em avogadro. 59 * 60 * In SBML Level 3 Version 2, if no math element is present in 61 * the FunctionDefinition, the function has no mathematical meaning 62 * defined in SBML Level 3 Core. This situation may arise when models 63 * are incomplete, or when additional meanings are provided by an SBML 64 * Level 3 package. 65 * 66 * @note Function definitions (also informally known as user-defined 67 * functions) were introduced in SBML Level 2. They have purposefully 68 * limited capabilities. A function cannot reference parameters or other 69 * model quantities outside of itself; values must be passed as parameters 70 * to the function. Moreover, recursive and mutually-recursive functions 71 * are not permitted. The purpose of these limitations is to balance power 72 * against complexity of implementation. With the restrictions as they 73 * are, function definitions could be implemented as textual 74 * substitutions---they are simply macros. Software implementations 75 * therefore do not need the full function-definition machinery typically 76 * associated with programming languages. 77 * <br><br> 78 * Another important point to note is FunctionDefinition does not 79 * have a separate attribute for defining the units of the value returned 80 * by the function. The units associated with the function's return value, 81 * when the function is called from within MathML expressions elsewhere in 82 * SBML, are simply the overall units of the expression in 83 * FunctionDefinition's 'math' subelement when applied to the arguments 84 * supplied in the call to the function. Ascertaining these units requires 85 * performing dimensional analysis on the expression. (Readers may wonder 86 * why there is no attribute. The reason is that having a separate 87 * attribute for declaring the units would not only be redundant, but also 88 * lead to the potential for having conflicting information. In the case 89 * of a conflict between the declared units and those of the value actually 90 * returned by the function, the only logical resolution rule would be to 91 * assume that the correct units are those of the expression anyway.) 92 * 93 * 94 * 95 */ 96 97 public class FunctionDefinition : SBase { 98 private HandleRef swigCPtr; 99 FunctionDefinition(IntPtr cPtr, bool cMemoryOwn)100 internal FunctionDefinition(IntPtr cPtr, bool cMemoryOwn) : base(libsbmlPINVOKE.FunctionDefinition_SWIGUpcast(cPtr), cMemoryOwn) 101 { 102 //super(libsbmlPINVOKE.FunctionDefinitionUpcast(cPtr), cMemoryOwn); 103 swigCPtr = new HandleRef(this, cPtr); 104 } 105 getCPtr(FunctionDefinition obj)106 internal static HandleRef getCPtr(FunctionDefinition obj) 107 { 108 return (obj == null) ? new HandleRef(null, IntPtr.Zero) : obj.swigCPtr; 109 } 110 getCPtrAndDisown(FunctionDefinition obj)111 internal static HandleRef getCPtrAndDisown (FunctionDefinition obj) 112 { 113 HandleRef ptr = new HandleRef(null, IntPtr.Zero); 114 115 if (obj != null) 116 { 117 ptr = obj.swigCPtr; 118 obj.swigCMemOwn = false; 119 } 120 121 return ptr; 122 } 123 Dispose(bool disposing)124 protected override void Dispose(bool disposing) { 125 lock(this) { 126 if (swigCPtr.Handle != global::System.IntPtr.Zero) { 127 if (swigCMemOwn) { 128 swigCMemOwn = false; 129 libsbmlPINVOKE.delete_FunctionDefinition(swigCPtr); 130 } 131 swigCPtr = new global::System.Runtime.InteropServices.HandleRef(null, global::System.IntPtr.Zero); 132 } 133 base.Dispose(disposing); 134 } 135 } 136 137 138 /** 139 * Creates a new FunctionDefinition using the given SBML @p level and @p version 140 * values. 141 * 142 * @param level a long integer, the SBML Level to assign to this FunctionDefinition. 143 * 144 * @param version a long integer, the SBML Version to assign to this 145 * FunctionDefinition. 146 * 147 * 148 * @throws SBMLConstructorException 149 * Thrown if the given @p level and @p version combination are invalid 150 * or if this object is incompatible with the given level and version. 151 * 152 * 153 * 154 * 155 * @note Attempting to add an object to an SBMLDocument having a different 156 * combination of SBML Level, Version and XML namespaces than the object 157 * itself will result in an error at the time a caller attempts to make the 158 * addition. A parent object must have compatible Level, Version and XML 159 * namespaces. (Strictly speaking, a parent may also have more XML 160 * namespaces than a child, but the reverse is not permitted.) The 161 * restriction is necessary to ensure that an SBML model has a consistent 162 * overall structure. This requires callers to manage their objects 163 * carefully, but the benefit is increased flexibility in how models can be 164 * created by permitting callers to create objects bottom-up if desired. In 165 * situations where objects are not yet attached to parents (e.g., 166 * SBMLDocument), knowledge of the intented SBML Level and Version help 167 * libSBML determine such things as whether it is valid to assign a 168 * particular value to an attribute. 169 * 170 * 171 */ public FunctionDefinition(long level, long version)172 FunctionDefinition(long level, long version) : this(libsbmlPINVOKE.new_FunctionDefinition__SWIG_0(level, version), true) { 173 if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve(); 174 } 175 176 177 /** 178 * Creates a new FunctionDefinition using the given SBMLNamespaces object 179 * @p sbmlns. 180 * 181 * 182 * 183 * The SBMLNamespaces object encapsulates SBML Level/Version/namespaces 184 * information. It is used to communicate the SBML Level, Version, and (in 185 * Level 3) packages used in addition to SBML Level 3 Core. A 186 * common approach to using libSBML's SBMLNamespaces facilities is to create an 187 * SBMLNamespaces object somewhere in a program once, then hand that object 188 * as needed to object constructors that accept SBMLNamespaces as arguments. 189 * 190 * 191 * 192 * @param sbmlns an SBMLNamespaces object. 193 * 194 * 195 * @throws SBMLConstructorException 196 * Thrown if the given @p sbmlns is inconsistent or incompatible 197 * with this object. 198 * 199 * 200 * 201 * 202 * @note Attempting to add an object to an SBMLDocument having a different 203 * combination of SBML Level, Version and XML namespaces than the object 204 * itself will result in an error at the time a caller attempts to make the 205 * addition. A parent object must have compatible Level, Version and XML 206 * namespaces. (Strictly speaking, a parent may also have more XML 207 * namespaces than a child, but the reverse is not permitted.) The 208 * restriction is necessary to ensure that an SBML model has a consistent 209 * overall structure. This requires callers to manage their objects 210 * carefully, but the benefit is increased flexibility in how models can be 211 * created by permitting callers to create objects bottom-up if desired. In 212 * situations where objects are not yet attached to parents (e.g., 213 * SBMLDocument), knowledge of the intented SBML Level and Version help 214 * libSBML determine such things as whether it is valid to assign a 215 * particular value to an attribute. 216 * 217 * 218 */ public FunctionDefinition(SBMLNamespaces sbmlns)219 FunctionDefinition(SBMLNamespaces sbmlns) : this(libsbmlPINVOKE.new_FunctionDefinition__SWIG_1(SBMLNamespaces.getCPtr(sbmlns)), true) { 220 if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve(); 221 } 222 223 224 /** 225 * Copy constructor; creates a copy of this FunctionDefinition. 226 * 227 * @param orig the object to copy. 228 */ public FunctionDefinition(FunctionDefinition orig)229 FunctionDefinition(FunctionDefinition orig) : this(libsbmlPINVOKE.new_FunctionDefinition__SWIG_2(FunctionDefinition.getCPtr(orig)), true) { 230 if (libsbmlPINVOKE.SWIGPendingException.Pending) throw libsbmlPINVOKE.SWIGPendingException.Retrieve(); 231 } 232 233 234 /** 235 * Creates and returns a deep copy of this FunctionDefinition object. 236 * 237 * @return the (deep) copy of this FunctionDefinition object. 238 */ public new clone()239 FunctionDefinition clone() { 240 global::System.IntPtr cPtr = libsbmlPINVOKE.FunctionDefinition_clone(swigCPtr); 241 FunctionDefinition ret = (cPtr == global::System.IntPtr.Zero) ? null : new FunctionDefinition(cPtr, true); 242 return ret; 243 } 244 245 246 /** 247 * Returns the value of the 'id' attribute of this FunctionDefinition. 248 * 249 * @note Because of the inconsistent behavior of this function with 250 * respect to assignments and rules, it is now recommended to 251 * use the getIdAttribute() function instead. 252 * 253 * 254 * 255 * The identifier given by an object's 'id' attribute value 256 * is used to identify the object within the SBML model definition. 257 * Other objects can refer to the component using this identifier. The 258 * data type of 'id' is always <code>SId</code> or a type derived 259 * from that, such as <code>UnitSId</code>, depending on the object in 260 * question. All data types are defined as follows: 261 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 262 * letter ::= 'a'..'z','A'..'Z' 263 * digit ::= '0'..'9' 264 * idChar ::= letter | digit | '_' 265 * SId ::= ( letter | '_' ) idChar* 266 * </pre> 267 * The characters <code>(</code> and <code>)</code> are used for grouping, 268 * the character <code>*</code> 'zero or more times', and the character 269 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers 270 * is determined by an exact character sequence match; i.e., comparisons must 271 * be performed in a case-sensitive manner. This applies to all uses of 272 * <code>SId</code>, <code>SIdRef</code>, and derived types. 273 * 274 * Users need to be aware of some important API issues that are the result of 275 * the history of SBML and libSBML. Prior to SBML Level 3 276 * Version 2, SBML defined 'id' and 'name' attributes on only a subset 277 * of SBML objects. To simplify the work of programmers, libSBML's API 278 * provided get, set, check, and unset on the SBase object class itself 279 * instead of on individual subobject classes. This made the 280 * get/set/etc. methods uniformly available on all objects in the libSBML 281 * API. LibSBML simply returned empty strings or otherwise did not act when 282 * the methods were applied to SBML objects that were not defined by the SBML 283 * specification to have 'id' or 'name' attributes. Additional complications 284 * arose with the rule and assignment objects: InitialAssignment, 285 * EventAssignment, AssignmentRule, and RateRule. In early versions of SBML, 286 * the rule object hierarchy was different, and in addition, then as now, 287 * they possess different attributes: 'variable' (for the rules and event 288 * assignments), 'symbol' (for initial assignments), or neither (for 289 * algebraic rules). Prior to SBML Level 3 Version 2, getId() 290 * would always return an empty string, and isSetId() would always return @c 291 * false for objects of these classes. 292 * 293 * With the addition of 'id' and 'name' attributes on SBase in Level 3 294 * Version 2, it became necessary to introduce a new way to interact 295 * with the attributes more consistently in libSBML to avoid breaking 296 * backward compatibility in the behavior of the original 'id' methods. For 297 * this reason, libSBML provides four functions (getIdAttribute(), 298 * setIdAttribute(@if java String@endif), isSetIdAttribute(), and 299 * unsetIdAttribute()) that always act on the actual 'id' attribute inherited 300 * from SBase, regardless of the object's type. <strong>These new methods 301 * should be used instead of the older getId()/setId()/etc. methods</strong> 302 * unless the old behavior is somehow necessary. Regardless of the Level and 303 * Version of the SBML, these functions allow client applications to use more 304 * generalized code in some situations (for instance, when manipulating 305 * objects that are all known to have identifiers). If the object in 306 * question does not posess an 'id' attribute according to the SBML 307 * specification for the Level and Version in use, libSBML will not allow the 308 * identifier to be set, nor will it read or write 'id' attributes for those 309 * objects. 310 * 311 * 312 * 313 * @return the id of this FunctionDefinition. 314 * 315 * @see getIdAttribute() 316 * @see setIdAttribute(string sid) 317 * @see isSetIdAttribute() 318 * @see unsetIdAttribute() 319 */ public new getId()320 string getId() { 321 string ret = libsbmlPINVOKE.FunctionDefinition_getId(swigCPtr); 322 return ret; 323 } 324 325 326 /** 327 * Returns the value of the 'name' attribute of this FunctionDefinition object. 328 * 329 * 330 * 331 * 332 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 333 * moved to SBase directly, instead of being defined individually for many 334 * (but not all) objects. LibSBML has for a long time provided functions 335 * defined on SBase itself to get, set, and unset those attributes, which 336 * would fail or otherwise return empty strings if executed on any object 337 * for which those attributes were not defined. Now that all SBase objects 338 * define those attributes, those functions now succeed for any object with 339 * the appropriate level and version. 340 * 341 * The 'name' attribute is 342 * optional and is not intended to be used for cross-referencing purposes 343 * within a model. Its purpose instead is to provide a human-readable 344 * label for the component. The data type of 'name' is the type 345 * <code>string</code> defined in XML Schema. SBML imposes no 346 * restrictions as to the content of 'name' attributes beyond those 347 * restrictions defined by the <code>string</code> type in XML Schema. 348 * 349 * The recommended practice for handling 'name' is as follows. If a 350 * software tool has the capability for displaying the content of 'name' 351 * attributes, it should display this content to the user as a 352 * component's label instead of the component's 'id'. If the user 353 * interface does not have this capability (e.g., because it cannot 354 * display or use special characters in symbol names), or if the 'name' 355 * attribute is missing on a given component, then the user interface 356 * should display the value of the 'id' attribute instead. (Script 357 * language interpreters are especially likely to display 'id' instead of 358 * 'name'.) 359 * 360 * As a consequence of the above, authors of systems that automatically 361 * generate the values of 'id' attributes should be aware some systems 362 * may display the 'id''s to the user. Authors therefore may wish to 363 * take some care to have their software create 'id' values that are: (a) 364 * reasonably easy for humans to type and read; and (b) likely to be 365 * meaningful, for example by making the 'id' attribute be an abbreviated 366 * form of the name attribute value. 367 * 368 * An additional point worth mentioning is although there are 369 * restrictions on the uniqueness of 'id' values, there are no 370 * restrictions on the uniqueness of 'name' values in a model. This 371 * allows software applications leeway in assigning component identifiers. 372 * 373 * Regardless of the level and version of the SBML, these functions allow 374 * client applications to use more generalized code in some situations 375 * (for instance, when manipulating objects that are all known to have 376 * names). If the object in question does not posess a 'name' attribute 377 * according to the SBML specification for the Level and Version in use, 378 * libSBML will not allow the name to be set, nor will it read or 379 * write 'name' attributes for those objects. 380 * 381 * 382 * 383 * @return the name of this SBML object, or the empty string if not set or unsettable. 384 * 385 * @see getIdAttribute() 386 * @see isSetName() 387 * @see setName(string sid) 388 * @see unsetName() 389 * 390 * 391 */ public new getName()392 string getName() { 393 string ret = libsbmlPINVOKE.FunctionDefinition_getName(swigCPtr); 394 return ret; 395 } 396 397 398 /** 399 * Get the mathematical formula of this FunctionDefinition. 400 * 401 * @return an ASTNode, the value of the 'math' subelement of this 402 * FunctionDefinition, or @c null if the math is not set. 403 */ public new getMath()404 ASTNode getMath() { 405 global::System.IntPtr cPtr = libsbmlPINVOKE.FunctionDefinition_getMath(swigCPtr); 406 ASTNode ret = (cPtr == global::System.IntPtr.Zero) ? null : new ASTNode(cPtr, false); 407 return ret; 408 } 409 410 411 /** 412 * Predicate returning @c true if this 413 * FunctionDefinition's 'id' attribute is set. 414 * 415 * 416 * 417 * 418 * The identifier given by an object's 'id' attribute value 419 * is used to identify the object within the SBML model definition. 420 * Other objects can refer to the component using this identifier. The 421 * data type of 'id' is always <code>SId</code> or a type derived 422 * from that, such as <code>UnitSId</code>, depending on the object in 423 * question. All data types are defined as follows: 424 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 425 * letter ::= 'a'..'z','A'..'Z' 426 * digit ::= '0'..'9' 427 * idChar ::= letter | digit | '_' 428 * SId ::= ( letter | '_' ) idChar* 429 * </pre> 430 * The characters <code>(</code> and <code>)</code> are used for grouping, 431 * the character <code>*</code> 'zero or more times', and the character 432 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers 433 * is determined by an exact character sequence match; i.e., comparisons must 434 * be performed in a case-sensitive manner. This applies to all uses of 435 * <code>SId</code>, <code>SIdRef</code>, and derived types. 436 * 437 * Users need to be aware of some important API issues that are the result of 438 * the history of SBML and libSBML. Prior to SBML Level 3 439 * Version 2, SBML defined 'id' and 'name' attributes on only a subset 440 * of SBML objects. To simplify the work of programmers, libSBML's API 441 * provided get, set, check, and unset on the SBase object class itself 442 * instead of on individual subobject classes. This made the 443 * get/set/etc. methods uniformly available on all objects in the libSBML 444 * API. LibSBML simply returned empty strings or otherwise did not act when 445 * the methods were applied to SBML objects that were not defined by the SBML 446 * specification to have 'id' or 'name' attributes. Additional complications 447 * arose with the rule and assignment objects: InitialAssignment, 448 * EventAssignment, AssignmentRule, and RateRule. In early versions of SBML, 449 * the rule object hierarchy was different, and in addition, then as now, 450 * they possess different attributes: 'variable' (for the rules and event 451 * assignments), 'symbol' (for initial assignments), or neither (for 452 * algebraic rules). Prior to SBML Level 3 Version 2, getId() 453 * would always return an empty string, and isSetId() would always return @c 454 * false for objects of these classes. 455 * 456 * With the addition of 'id' and 'name' attributes on SBase in Level 3 457 * Version 2, it became necessary to introduce a new way to interact 458 * with the attributes more consistently in libSBML to avoid breaking 459 * backward compatibility in the behavior of the original 'id' methods. For 460 * this reason, libSBML provides four functions (getIdAttribute(), 461 * setIdAttribute(@if java String@endif), isSetIdAttribute(), and 462 * unsetIdAttribute()) that always act on the actual 'id' attribute inherited 463 * from SBase, regardless of the object's type. <strong>These new methods 464 * should be used instead of the older getId()/setId()/etc. methods</strong> 465 * unless the old behavior is somehow necessary. Regardless of the Level and 466 * Version of the SBML, these functions allow client applications to use more 467 * generalized code in some situations (for instance, when manipulating 468 * objects that are all known to have identifiers). If the object in 469 * question does not posess an 'id' attribute according to the SBML 470 * specification for the Level and Version in use, libSBML will not allow the 471 * identifier to be set, nor will it read or write 'id' attributes for those 472 * objects. 473 * 474 * 475 * 476 * @return @c true if the 'id' attribute of this SBML object is 477 * set, @c false otherwise. 478 * 479 * @note Because of the inconsistent behavior of this function with 480 * respect to assignments and rules, it is recommended that callers 481 * use isSetIdAttribute() instead. 482 * 483 * @see getIdAttribute() 484 * @see setIdAttribute(string sid) 485 * @see unsetIdAttribute() 486 * @see isSetIdAttribute() 487 * 488 * 489 */ public new isSetId()490 bool isSetId() { 491 bool ret = libsbmlPINVOKE.FunctionDefinition_isSetId(swigCPtr); 492 return ret; 493 } 494 495 496 /** 497 * Predicate returning @c true if this 498 * FunctionDefinition's 'name' attribute is set. 499 * 500 * 501 * 502 * 503 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 504 * moved to SBase directly, instead of being defined individually for many 505 * (but not all) objects. LibSBML has for a long time provided functions 506 * defined on SBase itself to get, set, and unset those attributes, which 507 * would fail or otherwise return empty strings if executed on any object 508 * for which those attributes were not defined. Now that all SBase objects 509 * define those attributes, those functions now succeed for any object with 510 * the appropriate level and version. 511 * 512 * The 'name' attribute is 513 * optional and is not intended to be used for cross-referencing purposes 514 * within a model. Its purpose instead is to provide a human-readable 515 * label for the component. The data type of 'name' is the type 516 * <code>string</code> defined in XML Schema. SBML imposes no 517 * restrictions as to the content of 'name' attributes beyond those 518 * restrictions defined by the <code>string</code> type in XML Schema. 519 * 520 * The recommended practice for handling 'name' is as follows. If a 521 * software tool has the capability for displaying the content of 'name' 522 * attributes, it should display this content to the user as a 523 * component's label instead of the component's 'id'. If the user 524 * interface does not have this capability (e.g., because it cannot 525 * display or use special characters in symbol names), or if the 'name' 526 * attribute is missing on a given component, then the user interface 527 * should display the value of the 'id' attribute instead. (Script 528 * language interpreters are especially likely to display 'id' instead of 529 * 'name'.) 530 * 531 * As a consequence of the above, authors of systems that automatically 532 * generate the values of 'id' attributes should be aware some systems 533 * may display the 'id''s to the user. Authors therefore may wish to 534 * take some care to have their software create 'id' values that are: (a) 535 * reasonably easy for humans to type and read; and (b) likely to be 536 * meaningful, for example by making the 'id' attribute be an abbreviated 537 * form of the name attribute value. 538 * 539 * An additional point worth mentioning is although there are 540 * restrictions on the uniqueness of 'id' values, there are no 541 * restrictions on the uniqueness of 'name' values in a model. This 542 * allows software applications leeway in assigning component identifiers. 543 * 544 * Regardless of the level and version of the SBML, these functions allow 545 * client applications to use more generalized code in some situations 546 * (for instance, when manipulating objects that are all known to have 547 * names). If the object in question does not posess a 'name' attribute 548 * according to the SBML specification for the Level and Version in use, 549 * libSBML will not allow the name to be set, nor will it read or 550 * write 'name' attributes for those objects. 551 * 552 * 553 * 554 * @return @c true if the 'name' attribute of this SBML object is 555 * set, @c false otherwise. 556 * 557 * @see getName() 558 * @see setName(string sid) 559 * @see unsetName() 560 * 561 * 562 */ public new isSetName()563 bool isSetName() { 564 bool ret = libsbmlPINVOKE.FunctionDefinition_isSetName(swigCPtr); 565 return ret; 566 } 567 568 569 /** 570 * Predicate returning @c true if this 571 * FunctionDefinition's 'math' subelement contains a value. 572 * 573 * @return @c true if the 'math' for this FunctionDefinition is set, 574 * @c false otherwise. 575 */ public isSetMath()576 bool isSetMath() { 577 bool ret = libsbmlPINVOKE.FunctionDefinition_isSetMath(swigCPtr); 578 return ret; 579 } 580 581 582 /** 583 * Sets the value of the 'id' attribute of this FunctionDefinition. 584 * 585 * 586 * 587 * The string @p sid is copied. 588 * 589 * 590 * 591 * The identifier given by an object's 'id' attribute value 592 * is used to identify the object within the SBML model definition. 593 * Other objects can refer to the component using this identifier. The 594 * data type of 'id' is always <code>SId</code> or a type derived 595 * from that, such as <code>UnitSId</code>, depending on the object in 596 * question. All data types are defined as follows: 597 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'> 598 * letter ::= 'a'..'z','A'..'Z' 599 * digit ::= '0'..'9' 600 * idChar ::= letter | digit | '_' 601 * SId ::= ( letter | '_' ) idChar* 602 * </pre> 603 * The characters <code>(</code> and <code>)</code> are used for grouping, 604 * the character <code>*</code> 'zero or more times', and the character 605 * <code>|</code> indicates logical 'or'. The equality of SBML identifiers 606 * is determined by an exact character sequence match; i.e., comparisons must 607 * be performed in a case-sensitive manner. This applies to all uses of 608 * <code>SId</code>, <code>SIdRef</code>, and derived types. 609 * 610 * Users need to be aware of some important API issues that are the result of 611 * the history of SBML and libSBML. Prior to SBML Level 3 612 * Version 2, SBML defined 'id' and 'name' attributes on only a subset 613 * of SBML objects. To simplify the work of programmers, libSBML's API 614 * provided get, set, check, and unset on the SBase object class itself 615 * instead of on individual subobject classes. This made the 616 * get/set/etc. methods uniformly available on all objects in the libSBML 617 * API. LibSBML simply returned empty strings or otherwise did not act when 618 * the methods were applied to SBML objects that were not defined by the SBML 619 * specification to have 'id' or 'name' attributes. Additional complications 620 * arose with the rule and assignment objects: InitialAssignment, 621 * EventAssignment, AssignmentRule, and RateRule. In early versions of SBML, 622 * the rule object hierarchy was different, and in addition, then as now, 623 * they possess different attributes: 'variable' (for the rules and event 624 * assignments), 'symbol' (for initial assignments), or neither (for 625 * algebraic rules). Prior to SBML Level 3 Version 2, getId() 626 * would always return an empty string, and isSetId() would always return @c 627 * false for objects of these classes. 628 * 629 * With the addition of 'id' and 'name' attributes on SBase in Level 3 630 * Version 2, it became necessary to introduce a new way to interact 631 * with the attributes more consistently in libSBML to avoid breaking 632 * backward compatibility in the behavior of the original 'id' methods. For 633 * this reason, libSBML provides four functions (getIdAttribute(), 634 * setIdAttribute(@if java String@endif), isSetIdAttribute(), and 635 * unsetIdAttribute()) that always act on the actual 'id' attribute inherited 636 * from SBase, regardless of the object's type. <strong>These new methods 637 * should be used instead of the older getId()/setId()/etc. methods</strong> 638 * unless the old behavior is somehow necessary. Regardless of the Level and 639 * Version of the SBML, these functions allow client applications to use more 640 * generalized code in some situations (for instance, when manipulating 641 * objects that are all known to have identifiers). If the object in 642 * question does not posess an 'id' attribute according to the SBML 643 * specification for the Level and Version in use, libSBML will not allow the 644 * identifier to be set, nor will it read or write 'id' attributes for those 645 * objects. 646 * 647 * 648 * 649 * @param sid the string to use as the identifier of this object. 650 * 651 * 652 * @return integer value indicating success/failure of the 653 * function. @if clike The value is drawn from the 654 * enumeration #OperationReturnValues_t. @endif The possible values 655 * returned by this function are: 656 * @li @link libsbml#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS@endlink 657 * @li @link libsbml#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE@endlink 658 * @li @link libsbml#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE@endlink 659 * 660 * @see getIdAttribute() 661 * @see setIdAttribute(string sid) 662 * @see isSetIdAttribute() 663 * @see unsetIdAttribute() 664 * 665 * 666 */ public new setId(string sid)667 int setId(string sid) { 668 int ret = libsbmlPINVOKE.FunctionDefinition_setId(swigCPtr, sid); 669 return ret; 670 } 671 672 673 /** 674 * Sets the value of the 'name' attribute of this FunctionDefinition. 675 * 676 * 677 * 678 * 679 * The string in @p name is copied. 680 * 681 * @param name the new name for the SBML object. 682 * 683 * 684 * @return integer value indicating success/failure of the 685 * function. @if clike The value is drawn from the 686 * enumeration #OperationReturnValues_t. @endif The possible values 687 * returned by this function are: 688 * @li @link libsbml#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS@endlink 689 * @li @link libsbml#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE@endlink 690 * 691 * 692 */ public new setName(string name)693 int setName(string name) { 694 int ret = libsbmlPINVOKE.FunctionDefinition_setName(swigCPtr, name); 695 return ret; 696 } 697 698 699 /** 700 * Sets the 'math' subelement of this FunctionDefinition to the Abstract 701 * Syntax Tree given in @p math. 702 * 703 * @param math an AST containing the mathematical expression to 704 * be used as the formula for this FunctionDefinition. 705 * 706 * 707 * @return integer value indicating success/failure of the 708 * function. @if clike The value is drawn from the 709 * enumeration #OperationReturnValues_t. @endif The possible values 710 * returned by this function are: 711 * @li @link libsbml#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS@endlink 712 * @li @link libsbml#LIBSBML_INVALID_OBJECT LIBSBML_INVALID_OBJECT@endlink 713 */ public new setMath(ASTNode math)714 int setMath(ASTNode math) { 715 int ret = libsbmlPINVOKE.FunctionDefinition_setMath(swigCPtr, ASTNode.getCPtr(math)); 716 return ret; 717 } 718 719 720 /** 721 * Unsets the value of the 'name' attribute of this FunctionDefinition. 722 * 723 * 724 * 725 * 726 * In SBML Level 3 Version 2, the 'id' and 'name' attributes were 727 * moved to SBase directly, instead of being defined individually for many 728 * (but not all) objects. LibSBML has for a long time provided functions 729 * defined on SBase itself to get, set, and unset those attributes, which 730 * would fail or otherwise return empty strings if executed on any object 731 * for which those attributes were not defined. Now that all SBase objects 732 * define those attributes, those functions now succeed for any object with 733 * the appropriate level and version. 734 * 735 * The 'name' attribute is 736 * optional and is not intended to be used for cross-referencing purposes 737 * within a model. Its purpose instead is to provide a human-readable 738 * label for the component. The data type of 'name' is the type 739 * <code>string</code> defined in XML Schema. SBML imposes no 740 * restrictions as to the content of 'name' attributes beyond those 741 * restrictions defined by the <code>string</code> type in XML Schema. 742 * 743 * The recommended practice for handling 'name' is as follows. If a 744 * software tool has the capability for displaying the content of 'name' 745 * attributes, it should display this content to the user as a 746 * component's label instead of the component's 'id'. If the user 747 * interface does not have this capability (e.g., because it cannot 748 * display or use special characters in symbol names), or if the 'name' 749 * attribute is missing on a given component, then the user interface 750 * should display the value of the 'id' attribute instead. (Script 751 * language interpreters are especially likely to display 'id' instead of 752 * 'name'.) 753 * 754 * As a consequence of the above, authors of systems that automatically 755 * generate the values of 'id' attributes should be aware some systems 756 * may display the 'id''s to the user. Authors therefore may wish to 757 * take some care to have their software create 'id' values that are: (a) 758 * reasonably easy for humans to type and read; and (b) likely to be 759 * meaningful, for example by making the 'id' attribute be an abbreviated 760 * form of the name attribute value. 761 * 762 * An additional point worth mentioning is although there are 763 * restrictions on the uniqueness of 'id' values, there are no 764 * restrictions on the uniqueness of 'name' values in a model. This 765 * allows software applications leeway in assigning component identifiers. 766 * 767 * Regardless of the level and version of the SBML, these functions allow 768 * client applications to use more generalized code in some situations 769 * (for instance, when manipulating objects that are all known to have 770 * names). If the object in question does not posess a 'name' attribute 771 * according to the SBML specification for the Level and Version in use, 772 * libSBML will not allow the name to be set, nor will it read or 773 * write 'name' attributes for those objects. 774 * 775 * 776 * 777 * 778 * @return integer value indicating success/failure of the 779 * function. @if clike The value is drawn from the 780 * enumeration #OperationReturnValues_t. @endif The possible values 781 * returned by this function are: 782 * @li @link libsbml#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS@endlink 783 * @li @link libsbml#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED@endlink 784 * 785 * @see getName() 786 * @see setName(string sid) 787 * @see isSetName() 788 * 789 * 790 */ public new unsetName()791 int unsetName() { 792 int ret = libsbmlPINVOKE.FunctionDefinition_unsetName(swigCPtr); 793 return ret; 794 } 795 796 797 /** 798 * Get the <code>n</code>th argument to this function. 799 * 800 * Callers should first find out the number of arguments to the function 801 * by calling getNumArguments(). 802 * 803 * @param n an integer index for the argument sought. 804 * 805 * @return the nth argument (bound variable) passed to this 806 * FunctionDefinition. 807 * If the index @p n is invalid, @c null is returned. 808 * 809 * @see getNumArguments() 810 */ public getArgument(long n)811 ASTNode getArgument(long n) { 812 global::System.IntPtr cPtr = libsbmlPINVOKE.FunctionDefinition_getArgument__SWIG_0(swigCPtr, n); 813 ASTNode ret = (cPtr == global::System.IntPtr.Zero) ? null : new ASTNode(cPtr, false); 814 return ret; 815 } 816 817 818 /** 819 * Get the argument named @p name to this FunctionDefinition. 820 * 821 * @param name the exact name (case-sensitive) of the sought-after 822 * argument. 823 * 824 * @return the argument (bound variable) having the given name, or @c null if 825 * no such argument exists. 826 */ public getArgument(string name)827 ASTNode getArgument(string name) { 828 global::System.IntPtr cPtr = libsbmlPINVOKE.FunctionDefinition_getArgument__SWIG_1(swigCPtr, name); 829 ASTNode ret = (cPtr == global::System.IntPtr.Zero) ? null : new ASTNode(cPtr, false); 830 return ret; 831 } 832 833 834 /** 835 * Get the mathematical expression that is the body of this 836 * FunctionDefinition object. 837 * 838 * @return the body of this FunctionDefinition as an Abstract Syntax 839 * Tree, or @c null if no body is defined. 840 */ public getBody()841 ASTNode getBody() { 842 global::System.IntPtr cPtr = libsbmlPINVOKE.FunctionDefinition_getBody__SWIG_0(swigCPtr); 843 ASTNode ret = (cPtr == global::System.IntPtr.Zero) ? null : new ASTNode(cPtr, false); 844 return ret; 845 } 846 847 848 /** 849 * Predicate returning @c true if the body of this 850 * FunctionDefinition has set. 851 * 852 * @return @c true if the body of this FunctionDefinition is 853 * set, @c false otherwise. 854 */ public isSetBody()855 bool isSetBody() { 856 bool ret = libsbmlPINVOKE.FunctionDefinition_isSetBody(swigCPtr); 857 return ret; 858 } 859 860 861 /** 862 * Get the number of arguments (bound variables) taken by this 863 * FunctionDefinition. 864 * 865 * @return the number of arguments (bound variables) that must be passed 866 * to this FunctionDefinition. 867 */ public getNumArguments()868 long getNumArguments() { return (long)libsbmlPINVOKE.FunctionDefinition_getNumArguments(swigCPtr); } 869 870 871 /** 872 * Returns the libSBML type code for this %SBML object. 873 * 874 * 875 * 876 * LibSBML attaches an identifying code to every kind of SBML object. These 877 * are integer constants known as <em>SBML type codes</em>. The names of all 878 * the codes begin with the characters <code>SBML_</code>. 879 * @if clike The set of possible type codes for core elements is defined in 880 * the enumeration #SBMLTypeCode_t, and in addition, libSBML plug-ins for 881 * SBML Level 3 packages define their own extra enumerations of type 882 * codes (e.g., #SBMLLayoutTypeCode_t for the Level 3 Layout 883 * package).@endif@if java In the Java language interface for libSBML, the 884 * type codes are defined as static integer constants in the interface class 885 * {@link libsbmlConstants}. @endif@if python In the Python language 886 * interface for libSBML, the type codes are defined as static integer 887 * constants in the interface class @link libsbml@endlink.@endif@if csharp In 888 * the C# language interface for libSBML, the type codes are defined as 889 * static integer constants in the interface class 890 * @link libsbmlcs.libsbml@endlink.@endif Note that different Level 3 891 * package plug-ins may use overlapping type codes; to identify the package 892 * to which a given object belongs, call the 893 * <code>@if conly SBase_getPackageName() 894 * @else SBase::getPackageName() 895 * @endif</code> 896 * method on the object. 897 * 898 * The exception to this is lists: all SBML-style list elements have the type 899 * @link libsbml#SBML_LIST_OF SBML_LIST_OF@endlink, regardless of what package they 900 * are from. 901 * 902 * 903 * 904 * @return the SBML type code for this object: 905 * @link libsbml#SBML_FUNCTION_DEFINITION SBML_FUNCTION_DEFINITION@endlink (default). 906 * 907 * 908 * @warning <span class='warning'>The specific integer values of the possible 909 * type codes may be reused by different libSBML plug-ins for SBML Level 3. 910 * packages, To fully identify the correct code, <strong>it is necessary to 911 * invoke both getPackageName() and getTypeCode()</strong> (or 912 * ListOf::getItemTypeCode()).</span> 913 * 914 * 915 * 916 * @see getElementName() 917 * @see getPackageName() 918 */ public new getTypeCode()919 int getTypeCode() { 920 int ret = libsbmlPINVOKE.FunctionDefinition_getTypeCode(swigCPtr); 921 return ret; 922 } 923 924 925 /** 926 * Returns the XML element name of this object, which for 927 * FunctionDefinition, is always @c 'functionDefinition'. 928 * 929 * @return the name of this element, i.e., @c 'functionDefinition'. 930 */ public new getElementName()931 string getElementName() { 932 string ret = libsbmlPINVOKE.FunctionDefinition_getElementName(swigCPtr); 933 return ret; 934 } 935 936 937 /** 938 * Predicate returning @c true if 939 * all the required attributes for this FunctionDefinition object 940 * have been set. 941 * 942 * The required attributes for a FunctionDefinition object are: 943 * @li 'id' 944 * 945 * @return @c true if the required attributes have been set, @c false 946 * otherwise. 947 */ public new hasRequiredAttributes()948 bool hasRequiredAttributes() { 949 bool ret = libsbmlPINVOKE.FunctionDefinition_hasRequiredAttributes(swigCPtr); 950 return ret; 951 } 952 953 954 /** 955 * Predicate returning @c true if 956 * all the required elements for this FunctionDefinition object 957 * have been set. 958 * 959 * @note The required elements for a FunctionDefinition object are: 960 * @li 'math' inSBML Level 2 and Level 3 Version 1. 961 * (In SBML Level 3 Version 2+, it is no longer required.) 962 * 963 * @return a boolean value indicating whether all the required 964 * elements for this object have been defined. 965 */ public new hasRequiredElements()966 bool hasRequiredElements() { 967 bool ret = libsbmlPINVOKE.FunctionDefinition_hasRequiredElements(swigCPtr); 968 return ret; 969 } 970 971 972 /** 973 * Renames all the @c UnitSIdRef attributes on this element. 974 * 975 * 976 * 977 * In SBML, unit definitions have identifiers of type <code>UnitSId</code>. In 978 * SBML Level 3, an explicit data type called <code>UnitSIdRef</code> was 979 * introduced for attribute values that refer to <code>UnitSId</code> values; in 980 * previous Levels of SBML, this data type did not exist and attributes were 981 * simply described to as 'referring to a unit identifier', but the effective 982 * data type was the same as <code>UnitSIdRef</code> in Level 3. These and 983 * other methods of libSBML refer to the type <code>UnitSIdRef</code> for all 984 * Levels of SBML, even if the corresponding SBML specification did not 985 * explicitly name the data type. 986 * 987 * 988 * 989 * This method works by looking at all unit identifier attribute values 990 * (including, if appropriate, inside mathematical formulas), comparing the 991 * unit identifiers to the value of @p oldid. If any matches are found, 992 * the matching identifiers are replaced with @p newid. The method does 993 * @em not descend into child elements. 994 * 995 * @param oldid the old identifier. 996 * @param newid the new identifier. 997 */ public new renameUnitSIdRefs(string oldid, string newid)998 void renameUnitSIdRefs(string oldid, string newid) { 999 libsbmlPINVOKE.FunctionDefinition_renameUnitSIdRefs(swigCPtr, oldid, newid); 1000 } 1001 1002 } 1003 1004 } 1005