Do you want mixin syntax in JS, and if so, which semantics? In the prototype chain means super works.
-
-
Decorators don't have much to do w/ mixins. You can't super from your class into a mixin with a decorator (w/o mucking with the proto chain)
-
What's already possible is the class mixin pattern: let Mixin = (base) => class extends base { ... } class C extends Mixin(S) { ... }
-
Sure, but ergonomics of
@mixin class Base { is much nicer. Also usually don't need to super from class into mixin - code smell imo -
super calls are a fundamental composition primitive, they're critical for mixins to support.
-
What if multiple mixins conflict? Won't I need to track mixin order and then do super.super.super.method()? Best to just avoid in toto imo
-
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.
- 4 more replies
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.