I guess it is a design pattern, but was invented before we knew
that's what they were called. I disagree with the IBM article which
claims that single-inheritance was invented for safety. That's just %
@#$. Single-inheritance was invented because it is trivial to
compile. Multiple-inheritance is hard to compile. But it sure makes
the programmer's job easier. As I like to say:
"CPU-cycles we have plenty of, good programmer cycles we don't."
On 21 Dec 2005, at 15:02, Jim Grandy wrote:
And having now read the beginning of your reference, we are talking
about the same thing. What the Smalltalk paper calls traits is the
same concept as what Jam calls mixins.
I had thought that the original meaning of 'mixin' in Lisp was more
a design pattern built on multiple inheritance than a language
feature per se. The pattern meaning is certainly the meaning that
has carried forward in the C++ community. No matter.
jim
On Dec 21, 2005, at 11:50 AM, Jim Grandy wrote:
I guess I should have been more clear about where I was going with
this.
1- I think mixins (or something like that) are a great direction
for us in the future. In addition to your link (which I'd like to
read), I've also recently read two interesting papers on this topic:
"Applying Traits to the Smalltalk Collection Classes", linked from
http://www.iam.unibe.ch/~scg/Research/Traits/
"Scalable Component Abstractions", http://portal.acm.org/
citation.cfm?
id=1094815&coll=ACM&dl=ACM&CFID=63532963&CFTOKEN=67478546
The first argues for a well-defined semantics for compile-time
composition of simple mixins that don't otherwise participate in
the inheritance hierarchy. Basically, traits are standalone
classes (no superclass) that can be composed with each other and
used to modify the definition of a new class. I particularly like
the discussion of how the Smalltalk-80 collection classes explode
combinatorially without traits, although there are other
techniques that could be applied to improve that design.
The second argues from a static-typed functional language
perspective but has similar insights.
2- I'm also interested in ways we can get to a more compositional
architecture with the LFC and the components without necessarily
implementing something like traits or mixins. Something that
doesn't require compiler support, in other words. That's why I was
exploring the idea of using delegates to allow a node to modify
the behavior of a parent node -- its a manual technique, but
allows us to get started with a compositional architecture.
jim
On Dec 21, 2005, at 5:16 AM, P T Withington wrote:
Seems to me the transformer has the benefit of telling you what
it is really doing. The compiler could take advantage of that
knowledge (in the future) to be more efficient, e.g., by
attaching the attributes and methods to the class rather than the
instance when the parent is a class.
A transformer really is a mixin. I like this path, because it
means that we are continuing to reinvent Lisp :) (c.f., http://
www-128.ibm.com/developerworks/java/library/j-diag1203/). I can
pass on a copy of the JAM paper from TOPLAS if you are interested.
On 20 Dec 2005, at 18:02, Jim Grandy wrote:
Sorry, I actually missed your use of transformer. I was thinking
of something even simpler:
<class name="mouseattachment" extends="node">
<method event="oninit">
this.parent.mouseisin = false;
this.moverdel = new LzDelegate( this, "onmouseover", parent,
"onmouseover" );
this.moutdel = new LzDelegate( this, "onmouseout", parent,
"onmouseout" );
</method>
<method name="onmouseover">
this.parent.mouseisin = true;
</method>
<method name="onmouseout">
this.parent.mouseisin = false;
</method>
</class>
(I guess I could just answer my own question by trying this code
out. I'll do that if I get time tonight.)
jim
On Dec 20, 2005, at 2:44 PM, Jim Grandy wrote:
On Dec 20, 2005, at 1:48 PM, Adam Wolff wrote:
Anyway on Dec 20, Jim Grandy wrote:
[snip]
I've seen code in various places in the LFC and components
that creates
event handlers with reference attributes to hook into events
in a parent
view. Granted it is manual, not automatic like states, but
couldn't this
technique be used to build attachment classes that simply
register for
events at initialization?
[snip]
So are you proposing a transformer class (not like an LFC
transformer)
which tends to be used as a singleton and which takes LzNode
instances and
tinkers with them? e.g.
<transformer name="trMouseView">
<method name="transform" args="v">
v.addAttribute( "mouseisin" , false );
v.bindEventHandler( "onmouseover" ,
this.setMouseIsInTrue );
...
</method>
<method name="setMouseIsInTrue">
this.setAttribute( "mouseisin" , true );
</method>
...
</transformer>
A
Yes. Wouldn't this work? How does this require namespaces, five
bug fixes, or a change to the inheritance hierarchy?
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
