Are you explicitly requesting override in your boxmodel mixin?
On 2009-12-04, at 17:28, Max Carlson wrote:
> 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
>>> [email protected]
>
> --
> Regards,
> Max Carlson
> OpenLaszlo.org
