Re: [Laszlo-user] Three ways to do traits - a thought game

[jamesr]

I was making sure i didn't miss something important.. did you say that i 
can use the with keyword with instances rather then definitions?.. This 
is very important for me, because i would require the flexibility to use 
waypoints (a trait that will be discuss in a bit) on anything, not just 
classes (goes to test..) Ah, it did not work. Or more specifically, the 
following code does not compile, with the error message, "Compilation 
errors occurred:
org.openlaszlo.sc.CompilerError: mixins.lzx: 21: Error: Access of 
undefined property parameterized, in line: canvas.LzIn
stantiateView({attrs: {"with": parameterized}, "class": LzView}, 1);"
here's the source:

   <mixin name="parameterized">
       <attribute name="parameter" type="string" value="default string"/>
       <handler name="oninit">
           Debug.write("My parameter is %w", parameter);
       </handler>
   </mixin>
  
   <class name="testmixin" with="parameterized"/>
      
   <testmixin parameter="overridden string"/>
  
   <view with="parameterized"/>

what do you think the timeline is for doing something about it? I rate 
mixins as enough to do what i want (yay!) but i'm not entirely sure i 
shouldn't use both methods, where each one is appropriate. Here's how 
waypoints are used now:

<class name="foo">
   <waypoint named="something"/>
</class>

or

<view>
   <waypoint named="something"/>
</view>

Using mixins, we get

<class name="foo" with="waypoint" named="something"/>

and hopefully,

<view with="waypoint" named="something"/>

which doesn't read quite as clearly as the tagged trait version IMHO 
(may i call my current method "tagged traits"? thanks) but is 
suprisingly better then i thought and good enough for me, save that i 
must have instance application of the with keyword.

I write this as a reminder/opinion piece, and look forward to your comments


P T Withington wrote:
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