http://www.perlmonks.org?node_id=208858


in reply to Re: Make Perl an OO language
in thread Make Perl an OO language

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.

        - tye

Replies are listed 'Best First'.
•Re: (tye)Re: Make Perl an OO language
by merlyn (Sage) on Oct 29, 2002 at 21:14 UTC
    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
        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.