3 ms·
What's the practical distinction here? I agree with you that rust isn't OOP, but for the sake of communication and understanding--what's the practical differenc
by d4mi3n 2y ago
What's the practical distinction here? I agree with you that rust isn't OOP, but for the sake of communication and understanding--what's the practical difference between requiring a trait and inheriting from it?
- Rusky 2y agoIt means you can't just write `impl Bar for MyType` and get Foo pulled in automatically. You have to write both `impl`s yourself. The inheritance-like syntax is shorthand for `trait Bar where Self: Foo`, and bounds like this can show up in lots of other places, where they follow the same rules: `MyType` has to impl all of them, and the traits and bounds can have fairly arbitrary (or at least un-tree-like) relationships. The upcasting thing is a rare exception to the idea that this `Self: Foo` bound is just like any other bound.
- PeterWhittaker 2y agoIf Bar inherited from Foo, Bar would have Foo's methods. So if you implemented Bar for Gum, Gum would get Bar and Foo. But Bar requiring Foo means that if you want to use Gum in a place that expects Bar, Gum must have both Bar's methods and Foo's methods. In some cases, you might be able to derive some of those.
- pwdisswordfishz 2y agoFor one, each trait has a separate namespace for its items, so in particular Foo::quux and Bar::quux are distinct even when one trait "inherits" from the other.
- pjmlp 2y agoRust isn't classical Java OOP, that many keep conflating with OOP, there are many ways of OOP type systems in computer science. I have easily translanted the raytracing in one weekend from its OOP design in C++, into a similar OOP design in Rust.