After a little bit of usage of mixins it feels to me close to your point
#1 which you call traits.
Example:
<mixin name="hoverable">
<attribute name="hovering" .../>
<handler name="onmouseover">
...
</handler>
<handler name="onmouseout">
...
</handler>
</mixin>
<class name="box" with="hoverable"/>
- rami
jamesr wrote:
I'd like to throw out a thought about XML and how to achieve traits
using three different approaches that each have trade offs in ease of
use and flexibility. Posted just because.
1) the XML-DOM approach
this method relies on a two-pass compiler, where the first pass
processes the program expanding class definitions where indicated. It
would be purely xml based, so that when you have a definition
<trait name="hoverable">
<attribute name="hovering" .../>
<handler name="onmouseover">
...
</handler>
<handler name="onmouseout">
...
</handler>
</trait>
it can be applied to a class definition -- where "apply" means "copy all
the interior nodes from the trait to the definition" -- like so:
<class name='box" traits="hoverable"/>
2) you can use the builtin laszlo approach of "reference" handlers. the
reference attribute is a very powerful tool all by itself, and where
possible, writing my own classes, i include it. It can enable traits by
itself by listening to the parent, and by using javascript to directly
assign methods and function from the inner trait instance. You can
define it like so:
<class name="hoverable" extends="node">
<handler name="onmouseover" reference="parent">
...
</handler>
<handler name="onmouseout" reference="parent">
...
</handler>
</class>
and apply it like so
<class name="box">
<hoverable/>
</class>
The major benefit of this method is that it works now with no extra
runtime requirements, and you can pass arguments to your traits via
their instance tag! the bad news is that it requires a fully dynamic
environment to get the most out of it, the good news is that javascript
is capable of it and by extension laszlo can too. Another undiscussed
issue is that it can't be overridden easily -- if a baseclass and a
subclass both have a trait, you'll have a two traits, not one trait that
overrode the other; this is not as important as it sounds but there are
a few use cases.
3) using the mixins/formal entity approach. Because classes definitions
are extendable in javascript, you can actually build a traits model
without using either tricks in XML or relying on a dynamic environment,
using pure as3 code. This appears to be what the mixin is now, agree? I
have never used this approach but i imagine that it would be similar to
the XML example, where one couldn't pass parameters, however, unlike
like the first two example you would get a proper inheritance of traits
from base-class to sub-class "for free". However, it feels as if the
mixins are not locked down conceptually, something that we might get out
of the conversation.
Anyone care to mention a third way or some benefit/disadvantage i
overlooked?