In the prototype chain probably desugars into something like: function Mixin(Super) { return class extends Super { /* mixin here */ } }
-
-
Show this thread
-
The syntax could be something like: mixin Enumerable { ... } class MyList implements Enumerable {} but not ready for bikeshedding yet!
Show this thread
End of conversation
New conversation -
-
-
If you selected "We don't need mixins", is it because:
Show this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
doesn't that favors hierarchy instead of composition?
-
It doesn't favor it, but it offers it as an option.
-
If it's to avoid code duplication and have shared functionalities, I usually prefer decorators and utility functions, they're clearer. imho
-
I agree, usually!
-
plus we all know what "it offers it as an option" leads to :p
-
Eh not a huge fan of holding back useful tools for fear people might cut off their finger. Teams can use lints for that if they want.
-
sure, it depends on how you want to structure a framework, capabilities or conventions. I like the ember way of strongly suggesting the 2nd
-
Ember has both. Capabilities under the hood, conventions above it. Which I guess argues for decorators implementing mixins :)
- 1 more reply
New conversation -
-
-
IMO protocols like in Clojure or Elixir are far superior to Ruby-style mixins. I wouldn't like to see further encouragement of inheritance.
-
What about refinements in Ruby? fwiw "I don't want to see encouragement of inheritance" reads as zealotry to me.
-
Maybe it is a bit zealous, but I see inheritance as inherently (heh) bad. Any future language development should move away from inheritance.
-
Maybe that's an extreme opinion, but there are now tons of languages which prove that inheritance isn't necessary.
-
I don't think that's true. I think it's useful largely for frameworks, which have their place. Rust specialization shows this.
End of conversation
New conversation -
-
-
If the are implemented at all like Ruby Mixins, then
. Can easily get collisions without realizing it.https://gist.github.com/danny-andrews/cf363303bff4bb5ce4fa169cc16d2c39 … -
The biggest diff would be you can't see instance variables of superclasses.
-
Also JS symbols (and soon private methods) let you avoid collisions way more readily.
-
You could still get collisions in public methods those, like those the mixins actually expose/provide.
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.