I don't like perlboot, since it makes the all-too-common mistake for OO introductions of stressing inheritance to the point of making it seem like the whole point of OO is inheritance.

I do lots of OO programming and I don't use much inheritance. And when I do use inheritance, it is almost always interface inheritance using a purely virtual class that simply defines an interface and includes no implementation.

Unfortunately, Perl OO doesn't really support interfaces (unless you consider a simple list of method names to be an interface) so this type of inheritance is pretty pointless in Perl.

So I find inheritance to usually be the wrong answer in Perl. And yet I find lots of people who decide to "go the OO route" in Perl and immediately start thinking "what should inherit from what here?"

The point of OO, especially in Perl, is to nicely wrap all of your related data up into a convenient package that also knows the things that you can do with that data.

I find that if I'm writing a module, then it is best to just write it using OO, no matter how small it starts out to be. Without even thinking about it, you'll likely end up with a module that is much more robust in the face of being used from multiple parts of the same program and yet has a much lower risk of namespace collisions.

I don't like perlboot, since it makes the all-too-common mistake for OO introductions of stressing inheritance to the point of making it seem like the whole point of OO is inheritance.

Inheritance is only one of many topics. There's also "the magic first parameter" and "instance data" and "blessing" and "class methods versus instance methods". I wouldn't say inheritance is "stressed": they all get equal time in the examples. If there was anything less about inheritance, it wouldn't be in there at all. Would you prefer that? {sigh}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

The entire first part of the document covering several sections does the whole "you can have similar classes that have the same method name" dance that I somewhat inaccurately lumped under "inheritance" (since you can, at least in Perl, arrange for this without inheritance by just happening to use the same method name in each). I should have been more accurate and called it "polymorphism".

Many OO languages only achieve polymorphism via inheritance (so that the language can "check" your polymorphism for you). And I don't think I've run into any Perl classes that make use of polymorphism without using inheritance. And all of those sections sounded to me like an introduction to inheritance that didn't want to mention "inheritance" yet.

By my reading, I have to get just over 50% of the way through perlboot before we even mention the concept of data at all (after which we talk about inheritance some more) and it isn't until 85% of the way through before we see that you can have multiple items of data in a single object.

You have to get 85% of the way through the document before you see even mention of what is, to me, the single most important idea of OO (especially in Perl). So, yes, I don't like the approach it takes. Although grouping related data into a structure isn't unique to OO, it is still, to me, the most important piece. This is followed closely by grouping the methods that know how to deal with this data together (which is nearly the definition of an "object", to me).

And I think perlboot leads people into thinking about OO in a way that encourages (heck, makes OO seem pointless without) the use of features of OO that I think should be avoided (by which I don't mean "never used", just don't put them on the top of your list), especially in Perl.

        - tye