[Laszlo-dev] question about mixins

[Max Carlson]

BTW, this is causing compiler errors in swf10 for me, e.g.:
org.openlaszlo.sc.CompilerError: boxmodel.lzx: 40: Error: Method marked 
override must override another method, in line: override function 
$lzc$set_margin ($0) {

The method is invalid because it's not actually overriding anything on 
view...

P T Withington wrote:
> Yeah, you are right.  This was sloppiness on my part.
> 
> I think the right fix is for you to add a 'kind' attribute to ScriptClass, so that mixins and interfaces do not get emitted as js 'class', but have their appropriate type instead.  Then it is up to the script compiler back-end to decide what to do with mixins and interfaces, which hopefully it already does correctly.
> 
> On 2009-12-04, at 13:31, Henry Minsky wrote:
> 
>> While I'm tracking down the instance mixin bug with nested views, I was
>> noticing that when we declare a mixin
>> in LZX, we are emitting an actual class declaration for it into the output
>> object file.
>>
>> e.g., in source code you have
>>
>>   <mixin name="boxmodel">
>> ...
>> </mixin
>>
>> And that ends up emitting script code for
>>
>>                           dynamic class $lzc$class_boxmodel extends LzView
>> { ... }
>>
>> But is it really necessary to actually have the mixin  class as an
>> instantiable class at runtime? People aren't ever expected to instantiate
>> a mixin by itself, right? And the script compiler copies  out the methods
>> and attributes to construct interstitial
>> classes at compile time,  so  we don't actually need to emit an actual class
>> definition for the mixin class itself into the output file?
>> It wouldn't save much space in practice I guess, since most apps  don't have
>> a lot of mixins declared, but it would reduce the object file a little
>> if we didn't put these in..
>>
>>
>>
>> -- 
>> Henry Minsky
>> Software Architect
>> hminsky at laszlosystems.com
> 
> 

-- 
Regards,
Max Carlson
OpenLaszlo.org