why do you think UNIVERSAL::isa returning ref type is a bad design (the perl developers obviously don't think so...)? using UNIVERSAL::isa to establish ref type allows one to turn the array ref that used to be passed to a method into a blessed object (preferably a tie in this case to intercept internal data access) that lists the fictitious class 'ARRAY' as a (completely abstract) superclass (or interface if you prefer).

i do not think this is evidence of a bad design at all. it is just necessary to relax one's OO prejudices/convictions a little (which for perl OO, shouldn't be difficult ;-) ). on the contrary, i feel the 'ARRAY', 'HASH', etc pseudo classes ought to be used as marker interfaces (think java's Serialisable or Cloneable) to indicate the capability to be deferenced as a variable of that type (which, if the object supports a tie interface or has overloaded magic is really a method call in disguise). in other words, if isa( $thing, "ARRAY" ) returns true then $thing can be used as if it were a native array, regardless of exactly what $thing is, or how it implements array retrieval/storage. hooray for encapsulation *and* some nice parametric polymorphism as well.

and FWIW, using isa() in this manner is used in quite number of cpan modules.

Ok, I will give you credit that this is a very creative and elegant way to look at and use 'ARRAY', 'HASH', etc. But I think that co-opting the 'ARRAY' name is maybe not so good, for the simple reason that ref($thing) eq 'ARRAY' doesnt work. You have made the same word potentially mean 2 different thing in 2 different contexts. If you want a marker interface like Java, then why not just create one? Then your code can check for that interface explicitly, and you need never confuse your 'ARRAY' with Perl's 'ARRAY'. Also it seems to me that you are using UNIVERSAL (the Perl base class) as a module and not a class. You are mixing your paradigms here.

Yes, you have your encapsulation and parametric polymorphism, but at what cost? IMHO you are violating the principle of least surprise, what I think is a duck, isnt really a duck, you would need to be pretty sure that it quacks exactly like a duck or your well laid plans can come crumbling down. Otherwise you are making assumptions about the internals of the packages/objects you are passing your 'ARRAY' too (basically, what it does with your 'ARRAY') which then violates their encapsulation. This can get really messy when that client package/module is not written/maintained by you.

Yes I know I am anal about my OO, and I know that Perl's OO is a wide open field. But IMHO it could use a little more consitency. TMTOWTDI can still apply even within a more constrained object model.

why do you think UNIVERSAL::isa returning ref type is a bad design (the perl developers obviously don't think so...)?

I actually dont agree with alot of things the Perl developers did. And one of those things is how references are handled. References are currently clunky, and IMHO clearly an afterthought layed upon the original language. Most high-level languages do not force you to deal with things like this, i tend to view it as a sort of high-level memory management, and IMHO a high-level language should insulate you from such things. From what I have read on Perl 6, they are planning to make referencing and dereferencing automatic, but still allow the @{...} syntax to force dereferencing when you need it. But hey, this is just my opion, take it or leave it.

and FWIW, using isa() in this manner is used in quite number of cpan modules.

If quite a number of CPAN modules jumped off the brooklyn bridge, would you? ;-)

But seriously, I respect the elegance of your solution, I just dont agree with it. I myself spent several weeks debating if my class library should add some useful functions to UNIVERSAL, or to package those functions into small classes and use multiple inheritance. In the end, I decided to leave UNIVERSAL as it is, I just couldn't justify what i saw as "changing the language" just for my evil purposes.

-stvn

to be honest, i also feel that perl would gain a lot more brownie points from many quarters if it took OO just a little more seriously at the syntactic level (my pet hobby horse). i too would like to see some overarching consistency and unification of perl OO features with its OO contempories. although with greater consistency inevitably comes some loss of flexibility, i still have very high hopes for perl6. having coded OO perl at a very high level in a rather large OO perl app, its limitations are pretty clear to me -- perl needs method prototypes (in perl6), declarative types (in perl6), and good quality autogeneratable doco from src (possible with the first 2). also, OO should not have the rather large performance penalty it currently has in perl... but that is a minor thing compared to the others. i have recently needed to re-implement some old perl classes in c with OO perl wrappers due to speed and memory consumption becoming an issue.

matt