On 2009-11-17, at 15:24, 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
[...]
it can be applied to a class definition -- where "apply" means "copy all the interior nodes from the trait to the definition"
If you change the word `trait` to `mixin`, this is already implemented,
although not as a textual substitution as you describe, but by building actual
Javascript mixins and classes and using the underlying mixin substrate of the
compiler and core.
As I mentioned in previous emails to you (and to Rami), "trait" has come to have a very
narrow definition in computer science that does not encompass everything we wanted to do, so we
changed the name to "mixin", which is also a well-defined term in computer science and
more closely matches what we (and I think you) want to do. The name change was just a formality,
the functionality remained the same. At the same time, we cleaned up the implementation to be more
rigorous and fully supported. Also as mentioned, Henry is working on making it possible to add
mixins to individual instances (in support of our instance-first programming model).
Note that with the mixin approach you can parameterize the mixin -- it's
parameters become parameters of each class that it is mixed into:
<mixin name="parameterized">
<attribute name="parameter">
<handler name="oninit">
Debug.info("My parameter is %w", parameter);
</handler>
</mixin>
You can set the parameter when you mix it in:
<class name="one" with="parameterized">
<attribute name="parameter" value="1" />
<class>
<class name="two" with="parameterized">
<attribute name="parameter" value="2" />
<class>
Or when you instantiate:
<two parameter="too" />
2) you can use the builtin laszlo approach of "reference" handlers.
[...]
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.
This model seems an indirect way of achieving what can more directly be done
with mixins. The 'double inheritance' issue you allude to is a bone of
contention in O-O circles, but only when you have multiple inheritance. I am
not aware of any single-inheritance language that has this issue, so it does
not really apply here.
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.
The mixins that are exposed at the XML level are implemented using the mixin
substrate defined at the Javascript level, so there are no tricks, just normal
inheritance. There is not parameter issue, as I describe above.
The mixins _are_ locked down conceptually. They are a well-defined O-O
construct that we applied at the Javascript level to help make the core code
more modular and that we have exposed at the XML level to give OpenLaszlo
programmers the same power.
As I mentioned in my email to Rami, this is not without controversy. Some in
the O-O field feel that mixins are too powerful and just lead to trouble. We
feel they are a power tool, that if used judiciously, have more benefit than
risk.
I think you want to look more closely at mixins, since they are already
implemented, and see if they don't already solve the problem you are trying to
address. If they don't, let's talk about how we can improve them.
~ptw
