Forums

Hi all,

> I'm not sure why Neil thinks the functions are deprecated !

Largely because both my IDE and ant tell me. As does the source code:

/**
* Returns the value of the 'metaid' attribute of this object.
* ...
* @deprecated libSBML internal
*/
public String getId()
{
return libsbmlJNI.SBase_getId(swigCPtr, this);
}

However, while I understand the logic of deprecating this, I would
still quite have liked the base class NamedSBase or whatever with get/
set name/id in them... But I'll let it lie and implement a few helper
methods.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
England

On 5 Sep 2009, at 20:34, Sarah Keating wrote:

> Hi Guys
>
> NOTE: I changed the subject and really any further discussion on this
> topic should go to
> sbml-interoperability@caltech.edu
>
> I'm not sure why Neil thinks the functions are deprecated ! The
> functions
> on SBase are not documented, because the implementation on SBase is a
> helper function for existing users. New users should really use the
> set/get Id/Name functions on the appropriate derived class.
>
> Just for the record - sorry if I'm repeating myself :-)
>
> In libSBML-3 and earlier the id and name attributes were members of
> the
> base class SBase. This was a MISMATCH with the SBML specification.
> This
> inconsistency caused problems for new users. It also provided the
> opportunity to set an attribute on an element that did not in fact
> have
> that attribute - creating invalid SBML.
>
> In order to address these issues and pave the way for SBML L3
> extensibility, libSBML-4 moved the id and name attributes from SBase
> to
> the derived classes (where appropriate). This caused problems for
> existing users who use the base class to loop through different
> elements
> within the model and required set/get Id/Name. So libSBML-4 added the
> functions back to SBase as a helper function. These functions merely
> look at the SBMLTypeCode on the object and use a switch statement to
> cast the object
> to the appropriate class before calling the class specific function.
>
> SBMLTypeCode_t type = this->getTypeCode();
>
> switch(type)
> {
> case SBML_COMPARTMENT:
> return static_cast <const Compartment *> (this)->getId();
> break;
>
> ...
>
> LibSBML for SBML L3 core and earlier levels will have this
> functionality. However, once libSBML becomes extendible we anticipate
> that package developers will provide code for their own package which
> will communicate with the core libSBML but not impact the code
> directly.
> Thus as packages introduce new elements derived from SBase the
> facility
> to setId/Name from the SBase class may be lost.
>
> If you commonly use get/set Id/Name on an SBase object it may be worth
> implementing your own helper function to do this :-)
>
> Sarah
>
>
>
>
>
> ____________________________________________________________
> To manage your sbml-discuss list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>
> For a web interface to the sbml-discuss mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the sbml-discuss list,
> contact sbml-team@caltech.edu

____________________________________________________________
To manage your sbml-interoperability list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-interoperability

For a web interface to the sbml-interoperability mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-interoperability list,
contact sbml-team@caltech.edu

[Updated on: 17 Sep '09 21:35] by Moderator