[dojo-contributors] Improved mixin semantics

Scott J. Miles sjmiles at turboajax.com
Wed Aug 8 17:22:23 EDT 2007

In [10026] I've committed a refactored declare.js that has improved, 
hopefully robust, mixin semantics.

"inherited" should now work inside of mixin classes, and to travel into 
and out of mixin trees.

The basic syntax for inherited is like so:

dojo.declare("bar", [base, mixin, mixin2], {
   foo: function() {
     this.inherited("foo", arguments);

Note that the first argument must be the name of the function and the 
second argument must literally be 'arguments'. More on this below.

The inherited call will seek ancestral 'foo' in right-to-left order. 
Iow, first it looks in mixin2 (and up through it's ancestry) and then 
into mixin, and finally base.

I added a basic test in the test suite, hopefully you guys can bang on 
it and see if there are any flaws (ahem, see where the flaws are). 
Internally we've thrown some crazy structures at it and so far so good.

Wrt to the signature, I realize that it's odd, but it makes the magic 

Note that in Dean's Base2 he's solved this problem by RegEx'ing method 
code to detect the superclass call and then wrapping methods in closures 
as needed to setup the necessary info. This is clever as usual and makes 
most of the work into one-time preprocessing.

The benefit of declare is that it works regardless of how a particular 
method got into your class. That is, you can poke methods directly into 
prototypes or instances and 'inherited' should still work properly.

This was all a lot of work, so if you hate declare in general, or simply 
would prefer some other tack, please start a new thread and give your 
objective reasoning. I will be grateful as that will keep my head from 
exploding. :)

Scott J. Miles
TurboAjax Group

More information about the dojo-contributors mailing list