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]
