Nope, I wasn't. Henry's change takes care of the issue I was seeing.
P T Withington wrote:
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
-- Regards, Max Carlson OpenLaszlo.org
