If you selected "We don't need mixins", is it because:
Sometimes you're building a single method out of pieces, where each piece handles some subset of the params. Super good for this.
-
-
Like imagine implementing setAttribute and wanting mixins to handle each of the weird cases.
-
Intentional overrides, by definition, are not conflicts. Take away the ability to override, and you take away my ability to use them.
-
But a mixin solution without some sort of method resolution order, explicit or implicit is a problem. C3MRO is too magical IMO. Need better.
-
Ruby linearizes mixins, eliminating the need for a per-method MRO.
-
for an easy to reason Ruby-esque linearization... Is that solvable with a prototype based mixin in ES? -
JS actually already has linearization with: class SubClass extends Mixin1(Mixin2(BaseClass)) {} syntax.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.