> marine@ebi.ac.uk wrote:
>>> Andreas Draeger wrote:
>>>
>>>> Hi all,
>>>>
>>>> The methos setParentSBML in SBase and AbstractSBase can lead to a
>>>> destroyed SBML data structure. In previous versions the attribute
>>>> parentSBMLObject had the default modifier. This ensured that only
>>>> classes within the jsbml package were able to access this attribute
>>>> and
>>>> to change its value. This way pointers could not be set to objects
>>>> that
>>>> aren't actually the parent node in the SBML hierarchy. Having this
>>>> method set to public allows also other objects from the outside to
>>>> destroy the model and to create incorrect and invalid SBML. I'd like
>>>> to
>>>> set the modifier to the default value again.
>>>>
>>>>
>>> I thing, you would have to put it protected at least but I thing the
>>> problem is that the classes from Marine parser are using it may be.
>>> And classes that extends the basic elements for a level 3 package might
>>> want to use it.
>>>
>>> Create a tracker item may be ?
>>>
>>> Nico
>>>
>>
>> I don't use setParentSBML directly in the parser and if I did, it was a
>> mistake as I created a method setThisAsParentSBMLObject(AbstractSBase
>> sbase) which automatically set the current object instance as parentSBML
>> object of 'sbase'. This method also set the level and version of 'sbase'
>> if it is not set or check if the level and version of 'sbase' are the
>> same
>> as those of this object.
>>
>>
> So people can use your setThisAsParentSBMLObject(AbstractSBase) to mess
> up with the SBML hierarchy the same way as with setParentSBML ?
>
The problem is still the same yes. That's why I added that these methods
should be protected. I didn't call directly these method in the parser but
in the appropriate setxxx methods of each AbstractSBase elements so I
don't think it will be a problem to set the method
setThisAsParentSBMLObject to protected.
| 
18 Dec '09 07:25
