7 ms·
> Traits are interfaces So why not use "interface" keyword?
by EugeneOZ 11y ago
> Traits are interfaces
So why not use "interface" keyword?
- masklinn 11y agoBecause trait is a much better word for it: https://en.wikipedia.org/wiki/Trait_(computer_programming) https://en.wikipedia.org/wiki/Trait_(computer_programming)
- EugeneOZ 11y agoSo in Rust traits can include full methods bodies, not only signatures?
- evanpw 11y agoYes: http://rustbyexample.com/trait.html http://rustbyexample.com/trait.html
- pcwalton 11y agoYes. The feature has been proposed for Java too: "defender methods". Originally I resisted them on the grounds of not being necessary, but they're used all over now. Being able to supply a default implementation is extremely useful.
- oldmanjay 11y agoQuick correction: Java 8 does have defender methods.
- EugeneOZ 11y agoThanks to all for explanations! :) And now I think Traits are traits, but can be used as interfaces too :)
- kzrdude 11y agodefault method implementations makes traits behave like mixins, it's very useful (and it is a form of code reuse).
- pcwalton 11y agoTotally agreed. I was wrong to resist them :)
- deleted 11y ago[deleted]
- Manishearth 11y agoThey can also contain associated constants.
- GolDDranks 11y ago> Traits are somewhat between an interface and a mixin: an interface is made only of method signatures, while a trait includes also the full method definitions, on the other side mixins include method definitions, but they can also carry state through attributes while traits usually don't. Rust's traits may specify just a method signature and force the implementor of the trait to implement the method, but they may specify full definitions of methods too.
- ajross 11y agoProbably for the same reason that they call their unions "enums" or their heap blocks "boxes". Standardization of jargon has never been a thing with rust, just roll with it.
- steveklabnik 11y agoWell, enums aren't unions, they're tagged unions. And other languages call boxed values by that name too.
- ajross 11y agoStop it, they're unions. :) Among the target market, people are going to intimately familiar with the use of "enum" and "union" from the C language. Rust's concept of a single object that can store exactly one of several types of sub-objects matches one quite closely, and not the other. Having a runtime tag and affirmative checking doesn't change the nature of the thing. We don't call "cars" something different when we add cruise control or anti-lock brakes. "Enumerate" in English is just a fancy word for "count" -- it means to assign numbers to a bunch of things. Which is exactly what the C concept did. The Rust usage (to mean "something that can be in one of a few different states") is new, though Java has something fairly close too. It was a poor choice, sorry. Likewise being deliberately difficult with "trait" vs. "interface" (picking Self's jargon instead of the term that literally everyone already knows from decades of OOP) didn't serve you well. Thus we have blog posts like this needing to tell us what we probably should have been able to figure out from context. Finally, regarding "box" vs. "block". Other languages (C# is the only one that comes to mind off-hand) have used the idea of "boxing" to imply the allocation of space for and copying of pass-by-reference data. That's sort of a different notion than simple heap allocation, so it sort of gets its own jargon I guess. I didn't complain anyway. But with Rust, a "box" really is used to refer to a dynamic heap block in any context. We sort of already had a perfectly good word for that. Pretentious jargon isn't the worst crime in the world, but I do think Rust seems needlessly complicated in the way it likes to play Shakespeare with existing concepts.
- kinghajj 11y ago
- dragonwriter 11y ago> So why not use "interface" keyword? They aren't really interfaces. They can be like interfaces (just method signatures) or like classes without data (including definitions for some or all methods). Using a name distinct from either "class" or "interface" limits the degree to which incorrect expectations from similar-but-critically-different constructs in other language interfere with understanding of the Rust construct.
- seanmcdirmid 11y agoTraits as defined in scala can actually have state and data.
- Ygg2 11y agoDo Scala's traits change behavior depending on order of definition? That scares me tbh.
- seanmcdirmid 11y agoThere are ways to fix that, but I could never get Martin interested in my exclusive inheritance proposals. In particular, only one trait should be allowed to "implement" an abstract method in an object, although typical overriding is still unrestricted. It does require a new keyword (implement vs. override). As for overriding, traits could be ordered globally based on extension relationships and other fixed markers (e.g. Names).
- lmm 11y agoDepending on order of inheritance? Yes. And yes, it should scare you (though IME problems are rare and are obvious when they do occur). I love Scala but it's very much a language of awkward compromises.
- agumonkey 11y agoIt sits between interface and implementation. They're... more an `intermediate`.