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
