Le 10/07/2012 17:45, Sebastian Sylvan a écrit :
On Tue, Jul 10, 2012 at 4:15 AM, David Bruant <[email protected]> wrote:
Why having both classes and traits? Both are mechanisms to enable code
reuse.
I guess I should restate my question: In which case would I use traits over
classes or classes over traits?
As I understand it traits are the code-reuse parts, and classes are
little more than named records that actually bring a bunch of traits
together into an actual type. I.e. you don't inherit from other
classes.
Inheritance is very often associated with classes, so I didn't expect
that (I'm probably spending too much time with Java users :-p)
Traits are used to specify reusable bags of methods, and
classes are used to actually provide data types on which to run those
methods.
This model is very interesting. But if it's the case, why is it possible
to implement a trait per type? I'm referring to (in the proposal):
impl int: Ord {
fn lt(a: self) -> bool {
self < a
}
fn eq(a: self) -> bool {
self == a
}
}
In this case, the state is carried by the type (here 'int', which is a
bad example) which could be of arbitrarily complex structure with nested
vectors, tuples and records.
If I can "concretize" a trait for an arbitrarily complex structure, why
would I create classes? Or could classes be seen as syntactic sugar over
traits+types?
If it's the case, then the visibility control mechanism doesn't seem
necessary for traits anymore since visibility would be more a concern
for classes than for traits.
David
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
