Skip to content

Comment on Rust Any part 3: we have upcastsparent

Comments

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?

It 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.

If 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.

Rust 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.

For 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.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.