Mixins are supported on all runtimes. They are used in the javascript core,
but there are no (current) uses in any of the LZX components. There is an
example of using LZX mixins in test/mixins.lzx. That example was briefly
broken in trunk due to some other compile reorganization I am working on, but
it works again now.
On 2009-11-17, at 16:30, jamesr wrote:
> the question now is, do i take advantage of this to translate my traits file
> into compliance? Yes, it's not hard to do; i'll have a go at using it now.
> Does using mixins at all limit my ability runtime-wise?
>
> P T Withington wrote:
>> 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
