On Sun, 2004-02-22 at 11:34, stevan little wrote: > One thing that I noticed was that the authors seem to not intend > Traits to be thought of as being like Classes. As a matter of fact > they distinguish Traits from Classes in their "Trait Language" > (contained in the above paper). So the idea of just being able to > "inherit the darned thing", would not work as a Trait is not a Class.
Furthermore, roles are *not* inheritance. That's the point. Inheritance is not the be-all, end-all of OO, and any system that tries to fit everything into an inheritance-only model is irredeemably broken from the start. If inheritance always worked, we wouldn't need roles. > Traits too are "flattened" into the class that uses them, so there is > no true inheritance there. Traits themselves can be composed out of > other traits though, but again the flattening happens and no true > inheritance exists. The goal of inheritance is not to fit the world into one hierarchy. The goal of inheritance is to be able to write polymorphic code that does the right thing and is reasonably sure that any object you receive understands the method you're calling on it in the way that you intend. Unsurprisingly, that's also the goal of delegation, aggregation, composition, proxying, and reimplementation. Inheritance is only one way to accomplish that. Sometimes it's the best way. Many times, it's the worst way. That suggests that there's some deeper truth underlying all of the other polymorphic mechanisms. If that's true, you can build up all of those other systems on top of this mechanism. I think the base truth is roles, as seen in Perl 6. Again, the goal is polymorphism. Inheritance is just a means to that goal. If roles permit polymorphism separate from enforcing a particular implementation of marking polymorphic equivalence as well as code sharing, they'll be successful. See Class::Roles on the CPAN for one implementation in Perl 5. -- c
