To start with, coming from Javascript, and programming my fair share of OO Javascript, I can say that while i really liked prototype inheritance, but I found it not only difficult to work with at times, but downright impossible to explain its powerful aspects to anyone who was used to class-based OO. They are too stuck with the whole "class is a template not an object" idea, prototype-like stuff requires meta-classes in those languages, and that is just,.. well, lets not even get into meta-classes, they are so poorly understood and hardly ever agreed upon its not worth it.

As for Scott's comments about the GOD object and the state of Perl OO, I couldn't agree more with your assessments (although I dont think them as "across the board" as you seem too). But I dont agree that delegation and not inheritance are the ways to go. Delegation is a technique that has its place if it fits the domain model, but is not something that should replace inheritance. C++ programmers tend to lean towards delegation, and it (along with alot of the prevailing OO "wisdom") is really a direct symptom of the limitations of C++, not of OO. Just as some of the more convoluted Java-based "wisdom" (and some Design Patterns) tends to be a direct result of Java's single inheritance model. IMHO this is the language leading the direction of the theory. Its the cart before the horse.

Personally I like multiple inheritance. Not Mix-Ins. They are a different thing altogether, a sort of multiple inheritance hack if you will. But i would never ever think of trying multiple inheritance in C++, its cripplingly complex. Not because of the concept, but because of the implementation. And lets not even bother with Java and its sad excuse for multiple-inheritance in Interfaces. Java Interfaces are a waste of bytes.

For well done multiple inheritance, take a look at Eiffel. Sure the syntax of the language is downright weird, but the concepts are sound. Bertrand Meyer is one really smart muthafu... shut yo mouth.

Eiffel's solution to method conflict in multiple inheritance is to provide facilities to rename, undefine and join said methods. That's genius (again IMHO), and it solves 99% of all the multiple-inheritance complaints of C++.

As for roles, I like the idea, but I think the implementation is overkill. It seems to me to be a shortcut, rather than a solution. (And no i have not read the whole paper yet, I skimmed it a week ago when i saw it posted on the Perl 6 language list. I plan to give it a closer read over the holidays). But Roles, to me, seem to be a combination of multiple-inheritance and interface polymorphism. So why not just do multiple-inheritance with interface polymorphism?

I am currently constructing a class library/object framework at my company, in which we have implemented role-like behavior using multiple-inheritance and interface polymorphism in plain old OO Perl. I have created both a "redefines" and an "undefine" feature along with something I call a Dispatchable interface (which allows very specific method resolution (kinda like SUPER, but more specific)) to implement those Eiffel concepts in Perl.

We have a series of "interfaces" (and yes, our interfaces can have implementations unlike Java) that implement various bit of functionality (to be truthful, some dont actually implement anything but stub methods and are really just marker interfaces). Interfaces have no constructors and therefore cannot be instantiated. Some examples are: Printable, Cloneable, Dispatchable, Curryable, Comparable, Serializable, Sequencable, Throwable, Traversable, etc (you can get the idea from the names i think).

I have no base class (i dont believe in them), and so the hierarchy is wide and shallow instead of deep and complex. Multiple Inheritance is easy to control and manage within the framework, I have an IndexedTree class which i really nothing more than a combination of my Sequencable and Traversable interfaces with some renames and undefines. In fact, with very little work I can make a object capable of stringification, pretty reasonable deep cloning, method currying (basically pre-packaging a method and its instance as an anonymous subroutine along with your choice of pre-assigned arguments), and comparison abilities (the <=> is overloaded). An array like object is pretty much slapping a Sequenceable interface with a constructor and your done, same for hash-like object with the Keyable interface. Singletons can be implemented by implementing the interface and one method call (to initialize the instance).

Of course, we have not yet released this class lib, I am hoping to do so in early 2004 under the LGPL. (If anyone is interested in knowing more about it and possibly helping build/test/document it, feel free to msg me and I will see what i can do.)

As for Scott comments about type safety, I agree, type safety is cool. I love Ada 95 and that has to be the most draconian type model of them all (it had to be, the language was invented for the US Dept. of Defense to be used on its embedded software projects (read: nuke missiles)). But then again, look at languages like ML, which uses type inference rather than forcing you into some arcane type model. Mark Jason Dominus has a great presentation in ML and its type model, and how it all plays with Perl on his site , here is the link, its a good read.

So while I might agree with Scott that current Perl based OO is maybe not so good, I think that it is not the fault of Perl (which it seems from something you say Scott you dont either, but I am somewhat confused by your rant at the end).

In the end, I have found perl to be a great language to implement an OO framework in (better than the 12-15 other languages I have messed with and programmed in). Its freedom and flexibility can lead to bad ideas and even worse implementations, but that user-error, not Perl's fault.

Don't give up Scott, nothing is lost forever, the Perl community has it fair share of bad programmers, but so does every other language community (Java for example has ALOT). Perl's best hackers tend to be very smart and adaptable people, cut 'em some slack. :o )

-stvn

(p.s. - updated some wording, and formatting, as well as re-arranged some paragraphs so it reads a little smoother)

(p.p.s. - I just started reading the Traits/Roles paper, and it seems that is pretty much what I have been doing all along with my Interfaces, although I am a little more premisive with object state variables (but not too permissive))