Opened 12 years ago

Closed 12 years ago

#3030 closed enhancement (fixed)

dojo.declare() mixin specificity seems wrong

Reported by: alex Owned by: sjmiles
Priority: high Milestone: 0.9beta
Component: Core Version: 0.9
Keywords: Cc: alex
Blocked By: Blocking:

Description

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.

Change History (7)

comment:1 Changed 12 years ago by sjmiles

Status: newassigned

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.

comment:2 Changed 12 years ago by 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

comment:3 Changed 12 years ago by sjmiles

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

comment:4 Changed 12 years ago by sjmiles

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

comment:5 Changed 12 years ago by sjmiles

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

comment:6 Changed 12 years ago by sjmiles

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

comment:7 Changed 12 years ago by sjmiles

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.