I think saying that objects are only useful in so far as inheritance exists is
strange. The point of objects, as I've understood them, is to provide some form
of encapsulation - to be able to give limited access to certain data so that
you can maintain invariants on the data that are not expressible with a type
system (if such a system even exists). Objects can exist without inheritance
(and are still useful).
Inheritance seems to solve a different problem - how to write code that targets
many different types of objects in a simple way. But inheritance isn't really
needed there, just a way to deal with objects that behave like a certain thing,
or have a certain "interface". Java's interfaces, and rust's traits, seem to
solve this in a better way, because a single type can implement many interfaces
(and multiple inheritance is…. just bad).
The only thing that inheritance seems to provide that isn't covered by abstract
types (i.e., a module exports a type and not its constructor, so you can use
it, but only in the way defined by its interface) and interfaces (traits here,
or typeclasses in haskell) seems to be code reuse - i.e., you write a foo, and
then a specialized foo that reuses a bunch of code from foo. But you can
approximate that pretty well with traits as well (or you can have your
"superclass" as an attribute in your "subclass") - and I think you are left
with a more flexible system in general. Of course, that's just my opinion (and,
I am more of a functional programmer than an OO programmer).
destructors are provided (currently as a drop attribute in a struct), and will
(very shortly) be provided by implementing a Drop interface. i.e., you define a
drop method, and when the type goes out of scope, or is garbage collected, the
method is called. Again, I think this is more flexible, as it means that if you
don't need to have a destructor, you don't have to, but any type can have one
if it needs it.
I think it is better to think of rust as a functional language than an object
oriented language. Granted, these are all just words, and approximations at
best (as most languages incorporate things from all over the place), but I
think it explains some of the philosophy a little more.
As for your example, you can probably define an implementation for pairs, i.e.:
trait ShapeDrawing<(Sf,Sh)> {
…
}
Or even abstract it a little more into:
trait Drawable<A> {
…
}
and then:
trait ShapeDrawing<~[Drawable]> {
...
}
Etc. I might be mixing up the syntax a little, but the basic idea should be
correct. It is certainly a different approach, but I think you'll find that it
isn't less powerful (and you may find it to be more flexible - but you may
not!).
On Oct 6, 2012, at 2:14 PM, Eddy Cizeron wrote:
>
> Hello,
>
> I'm new to Rust, and I have some questions concerning some aspects of the
> language. From what I understand until now, rust has no dynamic linkage for
> methods as it would be the case in any standard OOP language. This is surely
> an intentionaly different philosophy from the current trend among other
> recent programming languages. But why not after all. I like the idea. So I
> find myself skeptical when I read the chapters of the documentation about
> OOP-like concepts like classes or interfaces.
>
> The essence of the "class" concept lies in the possibility to gather a data
> structure (a type) and the related processes that can act on the
> corresponding instances (methods) in a single bundle. But, tell me if you
> disagree, the only interesting purpose of such an operation is the ability to
> use inheritance. If no concept of inheritance exists, I hardly see what is
> the need of making functions "pets" for data. All we obtain are classical
> design issues like "is my 'f(a,b)' function a 'a.f(b)' method or a 'b.f(a)'
> method ?" (and I don't think the rust "resource" concept requires classes, as
> destructors or destructor-like functions are not methods). I'm afraid that
> the answer is merely to offer a supposedly "attractive" syntax for OOP users.
> And I think this would be a weak argument
>
> The concept of interface/implementation in rust is surely different than the
> usual one, but again to me it looks like it has some limitations due to the
> same reason than above: it tries to look OOP. I could have imagined a very
> similar interface concept but that does not focus on a single type:
>
> iface shape_drawing<Sf, Sh> {
> fn draw(Sf, Sh);
> fn bounding_box(Sh) -> bounding_box;
> }
>
> fn draw_twice<Sf, Sh with shape_drawing<Sf, Sh>>(surface: Sf, shape: Sh) {
> draw(surface, shape);
> draw(surface, shape);
> }
>
> Of course this example is a simple one. And any consistent system like this
> (if it does exist but I'm pretty sure it does) would have been more complex
> than the current one. But also more general and then more powerful.
>
> Let me clear about something: I don't expect anybody to change the current
> design. I'm nobody and I know it's always easier to criticize than to do
> things. I'm just expressing the feeling that while Rust tried to take a
> different direction from all the other new
> JVM-compliant-OOP-languages-with-functional-features (which I really really
> value very much) it seems it has not got rid of some conceptual patterns that
> are not, IMHO, necessary anymore. And I wish people could give their opinion
> about this.
>
> Thank you
>
> --
> Eddy Cizeron
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
