in Rust, methods should be object safe

https://nora.codes/post/methods-should-be-object-safe/

by fanf2 • 2 years ago

61 66 2 years ago

palata2• 2 years ago

It is a nice read!

I am not super familiar with the definition of "object-safe" (I read the docs but the definition is not completely trivial for me).

Does it work to say that an "object-safe" method mutates the object? That's what happens when you take `&mut self`, right?

But if I understood this correctly, I guess it means that a function without side-effect in Java should not really count as a method? Because in Java I call it a method whether it has a side-effect or not. Which corresponds exactly to the definition of `method` in the Rust docs, I think [1]. In C++, I would think that this is the difference between a const (no side-effect) and a non-const (side-effect) method.

[1] https://doc.rust-lang.org/reference/items/associated-items.h...

steveklabnik2• 2 years ago

Not every trait can be made into a trait object. Traits that are "object safe" can be made into a trait object. Nothing to do with mutation, or side effects.

palata2• 2 years ago

hmm... so there are object-safe methods and non-object-safe methods, and you can make a `Vec<YourType>` as long as `YourType` does not implement any non-object-safe methods?

throwup238• 2 years ago

It has to do with type erasure and knowing how big a type is in memory, not mutation. With traits, you can erase the implementing type and get back a vtable of a trait's method - called a trait object.

A trait is object-safe as long as no trait method returns the implementing type (like T::clone() -> T). Once it's a trait object, T is no longer known and the compiler doesn't know how much memory to allocate on the stack or heap, which makes it impossible to use. That's why trait objects have to be boxed or behind references - all pointers have a known size.

diarrhea• 2 years ago

A trait is object-safe as long as no trait method returns the implementing type (like T::clone() -> T)

That, and much more: https://doc.rust-lang.org/reference/items/traits.html#object... .

asa400• 2 years ago

This is the shortest, clearest explanation I've yet seen of object safety. Thanks.

sshine2• 2 years ago

I'll start off by disagreeing with the first sentence:

I think we should use “method”, in Rust

Just don't. Object-oriented programming is a 1980s buzzword. Let's help industry catch up.

I don't care if people call them functions or methods in daily speech. I even do that sometimes, depending on whom I'm talking to.

But let's not make up a highly technical definition of what a Rust method is.

Methods are loosely the same as functions that take a '&self', and only because your brain had that word for it, not because it's a good word.

alex_lav4• 2 years ago

Methods are loosely the same as functions that take a '&self', and only because your brain had that word for it, not because it's a good word.

Isn't this just true of any word with increased specificity? Why call it a square when we already have rectangle?

I'm not really seeing how understanding method vs. function is "highly technical". At least, not more technical than, I don't know, writing Rust code in the first place?

stouset4• 2 years ago

It’s just not a particularly useful distinction IMO. I have worked in C++, C#, Ruby, and Rust over the past 25 years of programming and outside of academic contexts I have never had a discussion with coworkers that hinged upon whether or not a particular function is, was, or ought to be a method.

In academic circles, there’s some meaningful distinctions to be made. In software engineering I’ve yet to find a place where having a very specific name mattered or reduced communication burden.

verandaguy• 2 years ago

Rust-specific nomenclature aside, I think it's useful in technical discussions to distinguish between (object) methods, class methods, and functions if your working language supports any combination of the three.

The word "method" is baked into the official Rust docs[0], and while I personally find the definition in the docs to be satisfying, I don't think the author's argument for narrowing that definition down is unreasonable or (more importantly) unworthy of discussion.

    [0] https://doc.rust-lang.org/rust-by-example/fn/methods.html

zamalek6• 2 years ago

Author is correct that Rust is not OOP. It simply has optional dispatch (which does not an OOP language make). I'm sure many of my fellow rustaceans will agree that the lack of OOP is one of the most competitive features of Rust.

pjmlp6• 2 years ago

Only those that never picked a Computer Science book on OOP type systems.

zamalek6• 2 years ago

Adhod. I have 18 years of professional experience with OOP, all of it a bloody waste of time. Exhibit: https://youtu.be/ns7jP1-SRvw?si=4NyOYebqtobIkFfC

echelon• 2 years ago

Rust is OOP. You can pass &self, self, etc. You can dynamic dispatch. It has a lot of great OOP features.

What Rust is not: class-based or inheritance-based (discounting default trait impls).

And this is a nice, modern form of OOP that discards orthogonal and useless design baggage.

zamalek6• 2 years ago

By that definition nearly every language is OOP, which makes the term useless.

lowbloodsugar3• 2 years ago

I always say it differently: OOP is a paradigm. I've done "object oriented programming" in C and in assembly. Might be more correct to say I've done things like polymorphism in C and assembly. By my definition, Rust can do OOP, even without dyn. I tend to take a very low-level view of things, since I was an assembly programmer before I was a C programmer. I think as Rust broadens its footprint, people are going to have to start using dyn more, and as they do, there'll be new patterns becoming idiomatic. The polymorphism-using-enums pattern is reasonable for tight code like embedded systems, but painful for applications generally.

zamalek6• 2 years ago

The polymorphism-using-enums pattern is reasonable for tight code like embedded systems, but painful for applications generally.

Rust rapidly becomes painful if you try to OOP in it. You would be better off using an OOP language for OOP. It wasn't voted the most loved language because people enjoyed learning lifetimes alongside all the accidental complexity OOP creates.

Dynamic dispatch is mostly seen in two circumstances: the type can't be known at compile time, and reducing code bloat as an optimization step.

sunshowers• 2 years ago

FYI: https://docs.rs/enum_dispatch

This doesn't work for every case of dynamic dispatch (it only works for what I call closed and semi-open universes of choices [1]), but it works for many of them. And there can always be a catch-all variant that uses a trait object.

[1] https://sunshowers.io/posts/open-closed-universes/

kibwen2• 2 years ago

Let's be precise about what definition of OOP we're each using.

In college, I (and I'm sure many others here) learned that OOP was about "abstraction, encapsulation, inheritance, and polymorphism".

But in practice, looking at the history of programming paradigms in industry, it seems like the real success of OOP was in dragging us away from "it's fine for mutable state to be global and/or scattered willy-nilly throughout your code" and towards "mutable state should be localized, tightly scoped, and/or coupled to the code that will be mutating it". Being generous to the academic definition, we could say that the only pillar of OOP that really mattered was encapsulation.

And by that definition, since Rust abhors global mutable state (but not mutation in general, as a functional language might do), it's not unreasonable to say that Rust, even if it doesn't have "objects" as Java or Smalltalk define them, still hews to the most useful parts of OOP.

logicchains• 2 years ago

"mutable state should be localized, tightly scoped, and/or coupled to the code that will be mutating it

Typical enterprise OOP did the opposite of this, coupling state to unrelated code via inheritance. To quote the creator of Erlang, when you want the banana it gives you the whole forest.

mrkeen3• 2 years ago

towards "mutable state should be localized, tightly scoped,

Ironically, the way to do actual encapsulation / localized-mutable-state is to just use stack variables - the C way.

Fields (what OOP added) are leakier and less localized than stack variables.

zamalek6• 2 years ago

In college, I (and I'm sure many others here) learned that OOP was about "abstraction, encapsulation, inheritance, and polymorphism".

This is what I was referring to. A problem that follows is that many of the Go4 patterns solve problems that OOP causes in the first place (obviously many others are universal).

Karellen• 2 years ago

    // counter_associated.rs
    [...]
            let c = Counter::increment(f);

What is `f` here?

jph• 2 years ago

Just a typo. It's meant to be `c` which is defined on the previous line.

tialaramex• 2 years ago

This is a strong reason to, either: Write your examples as Compiler Explorer links (or to some other playground tech, Rust has one to itself but it's easier to remember rust.godbolt.org) so you can see when your example doesn't work

Or, write in Markdown and use tooling to perform tests the same way Rustdoc does, if you wrote what claims to be code, just scoop it up and execute it, if it doesn't compile then we find out before we publish.

I'd say 80% of the time when I write more than one or two lines I write a bug, often it's a minor typo that the compiler would catch but sometimes it's a larger mistake and means I should re-evaluate my entire premise.

karma_pharmer• 2 years ago

"Object-safe" really ought to be called "dyn-safe".

thecodedmessage• 2 years ago

The word “method” already has a definition in Rust, which includes all intrinsic and trait methods. I feel like ‘dyn’ is relatively rarely useful and defining the term “method” based on what’s compatible with it is a bad idea.

bfrog• 2 years ago

People coming to rust attempting to apply typical OOP terms and patterns are likely to hit walls quickly. There’s are some things that of course look familiar. But it’s not where Rust came from, and it’s not what Rust provides.

in Rust, methods should be object safe

Related Stories