I agree with what you are saying, Tucker. That the mixin/class authors should now what they are doing. And I understand what André is saying, and the reasons for that.But having consistent behavior across runtimes would be good.
At the same time, wouldn't it be good to spit out a warning, so people who don't know LZX that well get hinted at the mistake they are making? On Fri, Jan 28, 2011 at 7:04 PM, P T Withington <[email protected]> wrote: > On 2011-01-28, at 12:31, André Bargull wrote: > >>> First, mixins are a power tool. To quote Uncle Ben: "With great power >>> comes great responsibility". >>> >>> You could either say the compiler is lazy about mixins, or you could say >>> the compiler tries to stay out of your way with mixins. I hold with the >>> latter. >>> >>> We don't have any special support at present for mixins to specify >>> requirements for the classes they mix in to (Lisp has support to this >>> effect, required-methods for instance). We could consider adding that at >>> some point. But I would say the error here lies with the mixin author, not >>> the compiler. The compiler can't possibly divine all the requirements a >>> mixin might have. To Andr?'s point, even what seems like an obvious >>> requirement (that a mixin with views must be mixed into a view) is not so >>> obvious when you consider all the power of LZX (dynamic placement of views). >>> >>> If you want to write a safer mixin, you can add your own requirements in an >>> init method. For instance, this mixin could verify that it ends up in an >>> instance of view in its init method and print out an error to the debugger >>> if it is not. It goes back to Uncle Ben: we give you great power with >>> mixins, and you take responsibility for their proper use. >>> >>> The real mystery to me is: why does the SWF10 version not error? That >>> seems like the real bug here. >> >> Not a real mystery, just the semantics of ActionScript3's `as` operator. >> >> From __LZinstantiationDone(): >> >> var vip:LzView = (this.immediateparent cast LzView); >> >> This gets compiled into: >> >> var vip:LzView = (this.immediateparent as LzView); >> >> Which is the same as: >> >> var vip:LzView = (this.immediateparent is LzView ? >> LzView(this.immediateparent) : null); >> >> >> So the `as` operator coerces its operand to `null` if the type check fails. > > Ouch. > > That 'feature' conspires with the conditional (which clearly had a different > purpose) to make things succeed. I guess we could fix Raju's original > complaint by making DHTML behave like swf10 and not try to add ourselves as a > subview if our immediate parent does not take subviews... >
