I don't know much about laszlo internals, but could it be possible to
treat mixins in a manner similar to XML namespaces? In my head, you
would begin by adding a "namespace" for the mixins that you wanted to
use. Then, using an attribute from a mixin (i.e. the target attribute
from the dragmatchable mixin) would look something like
dragmatchable:target="$once{someobj}". This would solve, I think, the
overall clarity issue mixins present. Again, I don't know if this type
of syntax is even possible in laszlo or what level of work it would take
to implement, but I wanted to throw it out for more informed brains than
mine to decide on.
Regards,
Tony
On 12/6/09 10:52 AM, Raju Bitter wrote:
> 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.
>>
>
