this post was submitted on 11 May 2024
8 points (78.6% liked)
Rust
5935 readers
5 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
In my experience taking a term that is widely used and attempting to give it a more specific meaning doesn't end well. If people are using "method" interchangeably with "associated function" right now it will be an endless battle of trying to make people stop using the term "sloppily" when it isn't sloppy it was just the original meaning.
I could understand method = associated function whose first parameter is named
self
, so it can be called likeself.foo(…)
. This would mean functions likeVec::new
aren’t methods. But the author’s requirement also excludes functions that take generic arguments likeExtend::extend
.However, even the above definition gives old terminology new meaning. In traditionally OOP languages, all functions in a class are considered methods, those only callable from an instance are “instance methods”, while the others are “static methods”. So translating OOP terminology into Rust, all associated functions are still considered methods, and those with/without method call syntax are instance/static methods.
Unfortunately I think that some people misuse “method” to only refer to “instance method”, even in the OOP languages, so to be 100% unambiguous the terms have to be:
impl
block.self
(even if it takesSelf
under a different name, likeBox::leak
).self
, so it can be called likeself.foo(…)
.I'd call instance methods just methods, it fits more into how the word is commonly used.
The omission is just way to easy not to use.
Yes, I agree with your clarification of commonly in use terms.