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.
-scott
(edited repeatedly to make use of terminology
consistent, include the link to mixins, re-arrange the
slurs slightly)