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...
