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.

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.

Howdy!

I've been wrestling once again with another pet project. I have inherited a C library that I want to implement in Perl. The data being handled seems to have a strong inclination toward OO-ness. Since I have been getting familiar with Design Patterns (Gamma, et al), I have been trying to identify uses for the patterns in my scheme.

One element is a "Category". These come in two flavors - "CatalogCategory" (permanent) and "ScratchCategory" (ephemeral). I have a bunch of methods that would be class methods in Category along with a number of object methods. I have come up with a "Categories" class which will be a singleton and contain a factory method that will provide "Category" objects as needed. Since I have other types of elements that behave similarly, I have cobbled together a Class::FlyweightFactory module to simplify setting the factories up...

yours,
Michael

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...

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.