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.
On 2011-01-28, at 09:06, Raju Bitter wrote:
> I've done some testing with the mixin implementation. There is a bug
> if you define a mixin with a view child, and have the class using the
> mixin extend "node". Here's some example code:
>
> <canvas debug="true">
>
> <mixin name="mixin1">
> <view name="redView" width="100" height="100" bgcolor="red">
> </view>
> </mixin>
>
> <class name="class1" extends="node" with="mixin1">
> <handler name="oninit">
> var r = canvas.searchSubnodes("name", "redView");
> Debug.info("redView = ", r);
> Debug.info("redView.parent = ", r.parent);
> </handler>
> </class>
>
> <class1 />
>
> </canvas>
>
> The SWF10 runtime doesn't show any error, and the debug output is:
> INFO: redView = <view>#0 | /class1/@redView
> INFO: redView.parent = <class1>#2| class1
>
> The DHTML runtime throws a TypeError:
> Uncaught TypeError: Object class1 has no method 'addSubview'
>
> Guess the compiler would have to throw an error when a subclass of
> node uses a mixin which contains views. But then, I just realize that
> the compiler doesn't warn if you add a view to a subclass of node when
> not using a mixin. What should the compiler do in such a case?
