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: [EMAIL PROTECTED] [mailto:cellml-discussion- >> [EMAIL PROTECTED] 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 > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion > _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
