•Re: (tye)Re: Make Perl an OO language

[merlyn]

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.

[tye]

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

[ichimunki]

I have to wonder if you knew how to program OO before reading perlboot. I have a hunch you did. If so perlboot was not aimed at you. For me, however, perlboot was the first document that actually made it clear what OO was about. Other Perl-related OO documents can be very opaque in this regard.

Given the original exhortation was for Perl programmers to use OO, I'd think in that respect perlboot would be more useful than perltoot. I mean perltoot's all over the map, loaded with buzzwords, and has that awful my $class = ref($proto) || $proto; line in the constructor.

And while I might agree that perlboot is a bit heavy on the inheritance, I think it's important, especially if you find yourself doing any sort of GUI work. And if you ever go on to program in an OO language like Ruby, you will depend on inheritance for any non-trivial application. I also think the focus on methods at the beginning is great, because without useful methods an object is really just a struct or a hash.

Either way, if you ask me, perlboot succeeds marvellously at what it says it was intended to do: introduce non-OO-knowing Perl programmers to OO.