Re: [Laszlo-dev] how do I implement a mixin as in LZX?

[Raju Bitter]

Yes, that's of course much better. It's only confusing to see the JS2  
classes and mixins in the component code, since most of the developers  
won't be able to understand the code. I'll have more time to continue  
to the testing of the AV components in the next weeks.

Raju
On Jan 19, 2009, at 4:04 PM, Sarah Allen wrote:

Raju,

That makes sense.  Max and I are working to get them to be more  
normal LZX syntax now that swf9 is fully supported.

Sarah

On Jan 18, 2009, at 6:46 PM, Raju Bitter wrote:

Sarah,
there's a simple reason that JS2 syntax was used in the AV  
components. At the time when I converted the code to JS2 that only  
way to pass the AS3 import statements into a class. The  
#passthrough { }# directive - which can be used inside an LZX based  
class right now - wasn't available back then.

I based the AV classes on the drawview.lzx code, copying the mixin  
code into the AV classes. I never finished the work last year and  
passes the classes on to Max, since I was buried in work at that  
time.

- Raju

I guess I don't really understand why they were used in the a/v
extensions.  I'll take Max's word for it that the mediastream
implementation does nothing and remove the mixin there.

On Jan 9, 2009, at 8:44 AM, P T Withington wrote:

> Note that mixin's are a 'power feature'.  I consider them to still
> be experimental, which is why the documentation is scarce.  I  
don't
> want them to be public, because I am not ready to commit to
> supporting them.
>
> Also note that a <mixin> is very different from a `mixin`.  That  
is,
> the LZX version is quite different from the JS version.  The JS
> version is pretty much a standard implementation of what CS would
> consider a mixin (which is in CS considered a dangerous power  
tool,
> not to be used lightly -- it's why Java and C# don't have them).
> The LZX version is even crazier, because _I_assume_ an LZX mixin
> needs to know how to mix in child nodes, states, placement,
> handlers, constraints, etc., etc., etc. which are not something  
you
> have in a plain old O-O language.
>
> Bottom line:  mixins are an optimization and you should follow my
> usual rules about optimization when considering them:
>
> Rule 1:  Don't use them.
> Rule 2 (for experts only):  Don't use them yet.
>
> (paraphrased from M. A. Jackson)
>
> On 2009-01-09, at 07:50EST, Max Carlson wrote:
>
>> Since that mixin isn't really doing anything, you should be  
able to
>> just get rid of it.  See tests/mixin for an example of how to do
>> this in LZX, or http://jira.openlaszlo.org/jira/browse/LPP-2302  
for
>> the gory details.
>>
>> Once we get all the code converted back to LZX syntax, we might
>> want to add a mixin that implements the runtime-specific bits.
>>
>> Sarah Allen wrote:
>>> I'm refactoring the av mediastream component to be regular LZX,
>>> but I'm not familiar with the mixin syntax and I can find
>>> documentation about (no luck with google or the ref guide...  
maybe
>>> I'm blind)
>>> Here's the snippet that I want to write the "new" way...
>>> <script when="immediate"><![CDATA[
>>>   mixin NewmediastreamShared {
>>>       function NewmediastreamShared ( parent:LzView? = null ,
>>> attrs:Object? = null , children:Array? = null,  
instcall:Boolean  =
>>> false) {
>>>           super(parent, attrs, children, instcall);
>>>       }
>>>   }
>>> ]]></script-->
>>> (Trying to avoid that nasty setter bug, which I think is at the
>>> root of why recording is broken)
>>> Sarah
>>
>> --
>> Regards,
>> Max Carlson
>> OpenLaszlo.org
>