6 ms·

Awesome post Dan, thanks for writing and sharing! One thing caught my attention: >At Facebook, we extensively use traits in Hack which are fairly similar to m

Awesome post Dan, thanks for writing and sharing! One thing caught my attention: >At Facebook, we extensively use traits in Hack which are fairly similar to mixins. Nevertheless, we think that mixins are unnecessary and problematic in React codebases. Here’s why. >Mixins introduce implicit dependencies >Mixins cause name clashes >Mixins cause snowballing complexity When I read these three reasons, I actually felt identified with them even outside React, since these as pretty generic problems in "mixin-like" cases that I've seen, for example Ruby modules. So it got my attention the fact that you're (at Facebook) using Hack traits successfully. Why is that? Are any of those reasons you stated not true with Hack traits? (Maybe you don't have knowledge in Hack though, but any high level conceptual idea may help). Again, awesome post!

asQuirreL 10y ago
Traits and mixins are different. A trait/interface/protocol doesn't generally contain implementation, and when it does, it is based only on other methods in the trait (for things like default implementations), whereas mixins are just fragments of a class implementation with potentially arbitrary dependencies on methods. So traits document the dependencies that mixins make implicitly. Traits in typed languages can only cause name clashes if two methods in different traits have the same name and the same type signature. This is immediately obvious, and the compiler will warn you so you can fix it there and then when you try and implement them both for one class. (It also brings into question whether there should be another trait to hold that shared method). The snowballing complexity that is mentioned stems from all those implicit dependencies: There's no way of knowing what they all could be in a nest of related mixins, whereas the corresponding traits document it and provide a map, of sorts.
- leogcrespo 10y ago
  Thanks for your response. I can see how type checking helps with that in Hack, that makes a lot of sense. Guess that in the case of Ruby for example we'd still have the same disadvantages as in JS right? Since there's still the possibility of calling methods in other modules and even in the class where the module is included, since that is discovered at runtime and you don't have any hierarchy that restricts who can call what.

asQuirreL 10y ago

Traits and mixins are different. A trait/interface/protocol doesn't generally contain implementation, and when it does, it is based only on other methods in the trait (for things like default implementations), whereas mixins are just fragments of a class implementation with potentially arbitrary dependencies on methods. So traits document the dependencies that mixins make implicitly. Traits in typed languages can only cause name clashes if two methods in different traits have the same name and the same type signature. This is immediately obvious, and the compiler will warn you so you can fix it there and then when you try and implement them both for one class. (It also brings into question whether there should be another trait to hold that shared method). The snowballing complexity that is mentioned stems from all those implicit dependencies: There's no way of knowing what they all could be in a nest of related mixins, whereas the corresponding traits document it and provide a map, of sorts.

leogcrespo 10y ago
Thanks for your response. I can see how type checking helps with that in Hack, that makes a lot of sense. Guess that in the case of Ruby for example we'd still have the same disadvantages as in JS right? Since there's still the possibility of calling methods in other modules and even in the class where the module is included, since that is discovered at runtime and you don't have any hierarchy that restricts who can call what.