Chronological Thread 

< Chronological >      < Thread >

---

Randall Britten wrote:
> That is a very good point.
>
> Perhaps what is needed is quite different altogether. A component like the
> sodium current needs a component to play the role of "membrane", and another
> component to play the role of "m gate" and another to play the role of "h
> gate" etc.
>
> I think what we are aiming to do is make sure that the component playing the
> role of "membrane" is connected to the appropriate variables, likewise, the
> component playing the role of "m gate" etc.
>
> This leads to the idea of specifying what roles a component can play, what
> roles it requires external components to play, and associating variables
> with the roles.
>
> Using Beeler-Reuter as an example:
> Component sodium-current needs components to play the following roles:
> membrane(variable: V) role;
> environment(variable: time) role;
> m-gate(variable: m) role;
> h-gate(variable: h) role;
> j-gate(variable: j) role.
>
> Component m-gate needs components to play the following roles:
> environment(variable: time) role;
> membrane(variable: V) role.
> (interestingly the current BR model lets the sodium current play both these
> roles for the m-gate).
>
> We are already doing this in a sense, but the possible roles are hard-coded
> to the unfortunately named "public" and "private": "in" means "requires",
> "out" means "provides".
>
I think that this discussion has now forked into two different aspects,
although they are somewhat intermingled.
1) Should we have a directionality to connections on interfaces?
2) Should we limit the number of interfaces to two, or should we
provide for more than two interfaces?

On the issue of directionality with respect to the Java analogy, I would
like to note that unlike CellML, Java is a procedural language, and so
while the concept of requires and provides makes sense for Java, it
probably makes less sense for a declarative language (I am not
suggesting that you are not aware of that, of course, but am merely
restating this by way of summary). Therefore, if we are going to break
compatibility in all cases, then a simple yes or no on each interface
will be sufficient, as opposed to an in, out, or none (unless we want to
assign an arbitrary direction for some other purpose).

On the issue of providing more than two interfaces, I agree that, in
some sense, it is rather unfortunate to be limited to a single hierarchy
with one interface going up, and one interface going down. However, this
hierarchy also interacts with other features like imports in a fairly
important way. We could redesign imports so that you get to choose which
interface to leave exposed, and which one to pull in grouped imports
from (currently, anything on the private facing side gets pulled in with
a component, while the public facing side is left exposed in the
importing model. If 'private' was to no longer have special meaning,
this would no longer make sense). This also gets messier because
encapsulated components can in turn have encapsulated components, and
any new, more generic system would need to provide new semantics to
replace this behaviour.

I think it also comes down to whether we would be prepared to make such
a major structural change for CellML 1.2 - it would inevitably delay the
production of a new specification quite substantially while all the
implications of the change were studied. If we decide not to do it for
CellML 1.2, it might still be worth thinking whether we could do
anything in 1.2 to ease the transition in the future.

Best regards,
Andrew

> The idea of specifying what roles a component can play is analogous to
> specifying what interfaces a Java class implements. The idea of specifying
> what roles a component requires other components to play is analogous to
> dependency injection, again from the Java world.
>
> Regards,
> Randall
>
>
>> -----Original Message-----
>> From: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion-
>> bounces at cellml.org] On Behalf Of Andrew Miller
>> Sent: Thursday, 10 January 2008 1:39 p.m.
>>
> ...
>
>> For example, the total sodium current in the Beeler-Reuter model is
>> meaningless to the parts which contribute to the sodium current, and
>> isolating them properly from each other helps prevent coding errors in
>> the encapsulated gate components. This makes the sodium current
>> variable, in the sodium current component, an example of when publicly
>> visible but privately hidden interfaces make sense.
>>
>>
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>

---

• [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Randall Britten, 01/10/2008
  • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Andrew Miller, 01/10/2008
    • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Randall Britten, 01/10/2008
      • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Andrew Miller, 01/10/2008
        • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Randall Britten, 01/10/2008
          • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Andrew Miller, 01/10/2008
            • [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2, Randall Britten, 01/10/2008

---

Archive powered by MHonArc 2.6.18.