dojo.declare() mixin specificity seems wrong

[alex]

if I specify this list of inheritance in a class:

[ Super1, Super2, Super3 ]

I would expect it to go from most to least specific, or the other way around (should that match a more established convention. What dojo.declare() does today meets neither expectation. First, it treats the first argument as highest specificity (mixin and prototype ancestor) and then it starts least-to-most specific traversal (as determined by mixin call order in ctor function). At a minimum, it would seem that the mixins should be called in the order:

Super3.call(this);
Super2.call(this);
Super1.call(this);

which lets Super2 and Super1 "win" out over Super3.

[sjmiles]

It's important to be mindful of the distinction between 'superclass' and 'mixins', but I agree that it's out of order now, which is a defect.

For:

class, [ super, mix1, mix2 ], props

The correct ordering for mixin should be:

superclass (this is always 'underneath'): mix1 <- mixed in first, can *override* superclass mix2 <- mixed in second, could *hide* mix1 props <- mixed in last, maximum precendence overrides

initialization:

superclass mix1 mix2 class

Unless declare is altered more significantly, as is under discussion, I will effect this change.

[sjmiles]

Ug, my reply got mangled, to try that again:

class, [ super, mix1, mix2 ], props

The correct ordering for mixin should be:

superclass <- this is always 'underneath' 
mix1 <- mixed in first, can *override* superclass 
mix2 <- mixed in second, could *hide* mix1 
props <- mixed in last, maximum precendence overrides

initialization:

superclass 
mix1 
mix2 
class

[sjmiles]

(In [8676]) Fix mixin specifity issue. Additional general optimizations. Refs #3030.

[sjmiles]

(In [8678]) Fix typos. Refs #3030.

[sjmiles]

(In [8705]) Messed up and forgot to commit updated test. Refs #3110, #3030.

[sjmiles]

(In [8708]) Trap extra calls to Object constructor. Refs #3030.