Forums

fine i give up ... what i meant is this:

http://cl.ly/8b0be9ce2f09627cb0a6

you get all the goodness of the 'rule-ness' so people that used the concept till now don't have to change a thing, and you still have the benefits of 'assignment-ness' that people want to take advantage of ... (people fearing this would look almost like multiple inheritance ... and would be un-implementable, don't: think in terms of interfaces and all the worries go away)

Cheers
Frank



On May 13, 2010, at 10:26 AM, Lucian Smith wrote:

> I couldn't follow Frank's ASCII art; is this what he's suggesting?
>
> Rule
> ==AlgebraicRule
> ==Assignment
> ====RateRule
> ====AssignmentRule
> ====InitialAssignment
> ====EventAssignment
>
> If so, it's OK insofar as it goes, but I don't see why we need to preserve
> the concept of a 'Rule' in the first place--the only commonality that I
> can see is that the three (AlgebraicRule, RateRule, AssignmentRule) all
> have the word 'Rule' in the name.
>
> -Lucian
>
> * Mike Hucka <mhucka@cds.caltech.edu> [2010-05-13 18:04] writes:
>> I like this idea. It would only minimally disrupt the current
>> class structure, and introduce a superclass that might help
>> package writers.
>>
>> What are other people's opinions?
>>
>> MH
>>
>>
>> On 27 Apr 2010, at 9:45 AM, Frank Bergmann wrote:
>>
>>>>
>>>> If we want a common base that is fine with me byt I
>>>
>>> I would prefer one ...
>>>
>>>>> would then like it to be:
>>>>>
>>>>> Assignment
>>>>> == Rule
>>>>> ==== AssignmentRule
>>>>> ==== AlgebraicRule
>>>>> ==== RateRule
>>>>> == InitialAssignment
>>>>> == EventAssignment
>>>>
>>>> You cannot do that because the AlgebraicRule does not have a
>>>> variable. So
>>>> you do not inherit anything.
>>>>
>>>
>>> Well ... then we need two abstract classes, in that case we won't
>>> loose what we have now (a concise way of talking about all rules).
>>>
>>> |---- AlgebraicRule
>>> Rule ------ |---- AssignmentRule --- |
>>> |---- RateRule --- |
>>> |----
>>> Assignment
>>> InitialAssignment --- |
>>> EventAssignment --- |
>>>
>>>
>>> Frank
>>>
>>>
>>>>> This is only because end users really could work only with the
>>>>> 'rule'
>>>>> objects. On the other hand I have no attachments to
>>>>> 'AlgebraicRule' either.
>>>>>
>>>>> Cheers
>>>>> Frank
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: sbml-discuss-bounces@caltech.edu [mailto:sbml-discuss-
>>>>>> bounces@caltech.edu] On Behalf Of Nicolas Le novère
>>>>>> Sent: Tuesday, April 27, 2010 6:40 AM
>>>>>> To: SBML Discussion List
>>>>>> Subject: [sbml-discuss] assignments
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I would like to bring an issue for specification developers. That
>>>>>> will
>>>>>> not
>>>>>> affect SBML support or usage. So everyone not concerned with spec
>>>>>> writting,
>>>>>> you can leave :-)
>>>>>>
>>>>>> At the moment, there is an abstract class in SBML definition,
>>>>>> called
>>>>>> Rule.
>>>>>> This class is a functional one (a semantic one), and is used to
>>>>>> create
>>>>>> the
>>>>>> concrete classes AssignmentRule, RateRule and AlgebraicRule.
>>>>>>
>>>>>> At the same time, there are in the SBML core four classes with
>>>>>> the same
>>>>>> syntax, that are used for a similar purpose:
>>>>>>
>>>>>> InitialAssignment
>>>>>> AssignmentRule
>>>>>> RateRule
>>>>>> EventAssignment
>>>>>>
>>>>>> Those construct share the same goal, to assign a value to
>>>>>> something, or
>>>>>> the
>>>>>> evolution of something. Although the attribute used to point to the
>>>>>> something varies, symbol or variable, the something is the same,
>>>>>> that
>>>>>> is a
>>>>>> species, a speciesReference, a compartment or a parameter.
>>>>>>
>>>>>> The abstract classes are not seen by the end users, and are mostly
>>>>>> constructs used to reduce redundancy in the specification of the
>>>>>> language.
>>>>>> Therefore, I think a good alternative to the current:
>>>>>>
>>>>>> Rule
>>>>>> == AssignmentRule
>>>>>> == RateRule
>>>>>> == AlgebraicRule
>>>>>> InitialAssignment
>>>>>> EventAssignment
>>>>>>
>>>>>> Would be:
>>>>>>
>>>>>> AlgebraicRule
>>>>>> Assignment
>>>>>> == AssignmentRule
>>>>>> == RateRule
>>>>>> == InitialAssignment
>>>>>> == EventAssignment
>>>>>>
>>>>>> The effect is mild on the core, but propagate on the various
>>>>>> packages.
>>>>>>
>>>>>> For instance, writing the package multi, we're now multiplicating
>>>>>> the
>>>>>> sections, UML diagrams and examples because the four assignments
>>>>>> can
>>>>>> affect
>>>>>> subpools (SpeciesTypeInstances) in addition of regular species.
>>>>>>
>>>>>> (Whether we want to keep AlgebraicRule in SBML core is another
>>>>>> story
>>>>>> ...)
>>>>>>
>>>>>> --
>>>>>> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-
>>>>>> Trust
>>>>>> Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:
>>>>>> +441223494521
>>>>>> Fax:
>>>>>> 468,Skype:n.lenovere,AIM:nlenovere,MSN:nlenovere@hotmail.com(NOT
>>>>>> email)
>>>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/,
>>>>>> @lenovere
>>>>>>
>>>>>>
>>>>>> ____________________________________________________________
>>>>>> 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-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
>>>>
>>>>
>>>> --
>>>> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-
>>>> Trust
>>>> Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:
>>>> +441223494521
>>>> Fax:
>>>> 468,Skype:n.lenovere,AIM:nlenovere,MSN:nlenovere@hotmail.com(NOT
>>>> email)
>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/,
>>>> @lenovere
>>>>
>>>>
>>>> ____________________________________________________________
>>>> 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-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-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-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-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