Opened 14 years ago
Closed 14 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 14 years ago by
Status: | new → assigned |
---|
comment:2 Changed 14 years ago by
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 14 years ago by
comment:5 Changed 14 years ago by
comment:7 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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:
The correct ordering for mixin should be:
initialization:
Unless declare is altered more significantly, as is under discussion, I will effect this change.