Good point. Another thing to consider is how IDE and tool support can be 
implemented for mixins. There should be better tools for coding LZX in the 
future, and would an Eclipse plug-in have an easy way to detect which 
attributes/methods are available for a class based on the current mixin syntax?

It's maybe not the most important thing, but I consider tool support to be very 
important.

- Raju

On Dec 4, 2009, at 11:41 PM, jamesr wrote:

> 
> 
> Rami Ojares / AMG Oy wrote:
>> > jamesr wrote:
>> > Again, i don't believe a mixin is the way to go.
>> > my major complaint is that when you use the with keyword,
>> > unless you read the documentation for the mixin,
>> > how do you know what attribute applies to what mixin?
>> > This relates to my previous conversation about how to do traits (mixins, 
>> > etc) in laszlo.
>> 
>> Previously you mentioned 3 ways to implement what you call traits.
>> - First one was exactly what mixins are now in laszlo.
>> - Second one was a way to emulate partially the functionality of mixins 
>> without actually using mixins.
>> - Third option I could not understand.
>> 
>> Then you go on to say that unless you read the documentation of a mixin you 
>> use you don't know what it will do.
>> But this applies to classes, too.
>> So should we do away with classes, too?
>> In fact I am not aware of any type of component that you can safely use 
>> without knowing anything about it.
>> 
>> Summa summarum: I would like to hear what exactly you feel is wrong with 
>> mixins.
>> 
>> With outmost respect and reverence,
>> Rami Ojares
>> 
>> 
>> 
> 
> If you use the method of "traiting" that uses the reference attribute of 
> handlers, then you will always have context. consider this chunk:
> 
> <view>
>   <margin padding="20"/>
> </view>
> 
> from this it is obvious that the padding attribute applies to the margin 
> characteristic. A new user can tell from this context exactly what is 
> occurring. If we have
> 
> <view with="boxmodel" padding="20"/>
> 
> then perhaps to you this is clear. Let's choose a more realistic example (in 
> my mind)
> 
> <view with="waypoint, boxmodel, draggable" named="foo" padding="20" 
> target="$once{someobj}"/>
> 
> can you tell me, from first glance, what attribute goes where?
> 
> Because mixins can be, well, mixin'd - it becomes very difficult to keep 
> attributes seperated when with a class definition, at least, you can learn 
> that a class name will always have the same attributes appplied, not so when 
> mixins are used, do you agree?
> 
> My concern is that although mixins are neat, they are actually providing 
> abilities the runtime *already* has, and has had for years. I do not believe 
> that mixins are universally better then the pattern that was started with 
> simplelayout, and ended with the library i wrote for using that pattern.
> 
> Should I elaborate? I think that you, I, and any other interested parties 
> would do well to find time to meet on IRC where we can type examples, come to 
> a conclusion, and then ask the community for their input.
> 
> with respects as well,
> 
> james.
> 

Reply via email to