in reply to A question of Inheritance

The @ISA array is used in a package to tell Perl where to find a method if that method is not defined in said package. This is known as "inheritance". If I want to subclass Foo as Foo::Bar, I would do this:

    package Foo::Bar;
    use strict;
    use Foo; # don't forget this line!
    use vars qw/ @ISA /;
    @ISA = qw/ Foo /;

[download]

That sets Foo as a base class of Foo::Bar. Further, if Foo has a base classes, Perl will search through them for a method call to a Foo::Bar object (or class method) in order to find something useful.

I can't think of any problems that using a scalar named $ISA would cause, but you are right that it could be bad form.

Now, since your question was "Void for Vagueness" :), I have to ask: did I answer it?

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Replies are listed 'Best First'.
Re: (Ovid) Re: A question of Inheritance
by dragonchild (Archbishop) on Dec 12, 2001 at 00:54 UTC
    Just to be nit-picky, this is what I tend to call "method inheritance" (aka "interface inheritance"). As opposed to "instance attribute inheritance" and "class attribute inheritance". @ISA will not coordinate the underlying data structures for you, nor will it do anything for package- or file-scoped variables.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]

      Just to nit-pick your nit-picking :), is that a limitation of @ISA or a limitation of Perl? If you wanted base classes to "inherit" class attributes, don't you pretty much need to have the base class export the data or inherit methods that will provide said data?

      I'd appreciate more discussion on this because Perl was my first exposure to writing OO code and now that I've been studying Java, I'm really beginning to see some of the limitations that Perl has in this area. In particular, I'd really appreciate being able to provide true method overloading, but I suspect Perl's variadic functions (and, perhaps, not being able to use prototypes with methods) are the reason this wasn't implemented, short of a generic method that uses an internal dispatch table based upon the contents of @_. Hmm... maybe I should add this to my XMas wish list :)

      Now there's an interesting thought for a meditation... how do Monks simulate missing OO features in Perl?

      • Method overloading
        Class::Multimethods

      • Data inheritence
        Class::Class? (unless I misread the docs)

      • Separate class and instance methods
        Bless the object into a separate package?

      • Others?

      Cheers,
      Ovid

      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
        First off, I don't see that Perl has any "limitations" when it comes to OO. I've been able to simulate every single OO feature I've ever wanted to have. You just have to be willing to either trust someone else's implentation (which is what you do for all other OO languages) or (what I do) roll your own.

        First off, I've never used any package to do OO work. I've never even looked at any code (other than Advanced Perl, and it didn't even work out of the box).

        What I do for data inheritance (both class and instance) is to have a virtual base class that does all that book-keeping for you. I've used $self->SUPER::new to do that, but I prefer the virtual base class.

        As for method inheritance - isn't that what @ISA provides for you? Well, more of method re-dispatch, but isn't that the same thing?

        As for class vs. inheritance methods ... If you have a huge amount of class methods vs. a small amount of instance methods, doesn't that mean you have a singleton? If you have a huge amount of instance methods and a small amount of class methods, doesn't that mean you're working with a set of objects that have a few book-keeping functions in the background? *shrugs*

        I guess I just don't see things as black and white and many others do. I write stuff. It gets the job done. I have fun doing it. I get paid. I go home to my fiancee and kids. :-)

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[reply]
[d/l]
        Missing OO functionality?

        There are many different pieces of functionality that can go into an OO implementation. One person will want to separate classes from instances. Another person wants to be able to inherit from prototypes. One person wants to have multiple inheritance. Another multiple dispatch. Another thinks that complexity is bad, single dispatch with single inheritance only.

        And so on.

        I don't think that Perl's selection of choices is particularly deficient as far as a wishlist of features goes. And as TheDamian points out in his book, it is possible to build on top of Perl's OO the ability to do the various things that the native OO doesn't directly do.

        So no. It isn't the, "Can't get there from here" issues that bug me about Perl's OO. Rather it is the feeling that there are seams where you can see that it was bolted on later, and there is a feeling of clumsiness about it. But it works pretty well for all that...

[reply]
        Well if we are talking about OO in general, one would have to say that perl does a pretty good job of handling one of the main attributes of said quest. Polymorphism. I love being able to right a method and not have to right 50 just to take care of all of the possibilities of what might get passed to it. The power to do this in an un-typed fashion makes perl, i believe, a very strong example of an OO-ified language.
[reply]
Re: (Ovid) Re: A question of Inheritance
by tradez (Pilgrim) on Dec 19, 2001 at 23:21 UTC
    Ovid, that was actually perfect. I knew I could count on the perlmonks for an answer!
[reply]

In Section Seekers of Perl Wisdom