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
