in reply to Will role-based programming be part of the standard Perl 6 distribution?

OO has existed for 30 years but hasn't been well understood by a significant group of programmers until now - and probably only 5 of them program Perl. Every bit of modern literature you'll pick up - "Refactoring: Improving the Design of Existing Code", "Design Patterns: Elements of Reusable Object Oriented Code", "Object Orienged Design Heuristics", or any other book written in the last 10 years that has sold well on the subject, all agree: delegation, not composition, is the only way to fly. That is, the only way to code with any sembelence of structure, modularity, robustness, and run-time and compile-time dynamicness.

"does" muddies the water, trying to make essentially inheritance (composition) more "powerful", but it isn't the right kind of power, and like computed symbol table entries and eval, the power lures programmers into doing things the wrong way because the wrong way is just SO easy, atleast initially.

The problem with inheritance, in a nutshell, is as you compose and compose, you wind up with one huge object that is an amalgamation of now no longer distinct parts - an "everything". Sort of like "everything" in the "Everything Engine". Each node is an embodiment of potentially everything. It includes all of the code. When one node relates to another, it relates to another everything. This isn't a critism of the everything engine - many programmers accidentaly discover that they've written exactly this through constant promotation of objects or records in a database. Saying to yourself over and over again "well, this is kind of like that, and sometimes it might need to do that, so we'll just make them both the same thing". Do you see where this is going? There is no relationship between parts, no structure. Aggregation (considering a structure of several objects) becomes almost impossible. Multiplicity (where one object has several of a subpart rather than just the one it gets through inheritance) becomes impossible.

This isn't bizarre and it isn't the least bit of a surprise to anyone who sticks their head out of the perl camp now and then. This is known as the God Object, and Perl programmers are infamous for repeating this sin over and over and over. We're called amatures and hacks because of our gross and sustained ignorance. Perl projects seldom stay maintainable as they grow large and are often thrown away and replaced with Java because of this blind spot in our collective software engineering know-how.

In Perl 4, when you used a "toolbox" module that had all of your routines in one place - that was a god object. In Perl 5, when you download a CPAN module that tries to be OO but is actually itself one huge object with no decomposition, that's a god object. Most fit this description - DBI, LWP/HTTP::*, and a few others are notable exceptions.

Adding more and more logic to a given class to compose something that embodies all of the behavior you want is also known as Mix Ins. This is one mechanism that god objects are arrived at by and one that Perl 6 is quite proud of. Hello?

And Perl 6 is formalizing all of this after two generations of Perl. When it should be making delegation easier.

Delegation is, in a word, structure. Rather than objects being (isa) other things, they reference them. The other object is seperate. Messages are propogated across the structure according to the Law of Demeter, which says that objects in a structure should only depend on the interface of objects immediately next to them, and those objects should depend on those immediately next to it, and messages should be propogated. The opposite is one object knowing and being dependent and hardcoded to the structure of the entire jumbled of objects - a trait of god objects and the only practise of Perl programmers.

Perl can't do objects right. It isn't a problem anywhere in C code - it is a cultural one. It is like trying to teach apes to hold tea parties. Perl will never stand on the same ground as Java, C++, C#, or any other language currently in fashion for thier object support. Larry Wall asked that the cultural be reinvented along with the language - very astute indeed. I've been evangalizing, doing PerlMongers presentations, blathering on IRC, trying to explain to perlers what type safety is, why 80% of new code written is in a language that has it, and why they should understand how it works even if they don't use it. You know how far I've gotten? No where. Perlers have their heads up their arses just as far as any Atari or Amiga users ever had and more and more it seems like Perl is going to go the way of the Atari ST. I'm sorry, I try really hard not to be inflamitory, but if I didn't *try* to sound a wake-up call, I wouldn't be doing my part.

So, for once, princepawn is right on - there is very little advantage to making inheritance more complex. It is a strawman for the real problem, but the problem stems from an ignorance that perlers will do nothing about.


(edited repeatedly to make use of terminology consistent, include the link to mixins, re-arrange the slurs slightly)