Suppose I come up with a type that doesn't inherit from IO::File, but has all the proper behaviors of IO::File. Why should you reject it?

All you should care is that when you send close to it, it closes. Hence, can is more appropriate than isa, almost every time.

Or, to avoid the overhead, just drop it into an eval block.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

a type ... doesn't inherit from ... but has all the proper behaviors of IO::File. Why should you reject it?

All you should care is that when you send close ... it closes. Hence, can is more appropriate than isa...

can tells me if by chance it has a method.
isa tells me it has all the proper behaviours by intent. Hence isa is almost always more appropriate than can.

I'm really not that sure where I sit in this argument, so I would be glad to read a clarification or rebuttal.

I got a laugh out of your example of first param a ref or class, as I've just forsworn the casual usage of

 bless $me, ref $self || $self;

as false laziness. And I drew a blank on any other ordinary usage.

{I said this in the CB... maybe you didn't see it.}

If I want to create a wrapper class that delegates rather than inherits, my class @ISA-not {grin} your precious IO::File, even though I'm using one internally, and delegating everything.

So, please, don't check isa. It's not the right thing to do for maximum re-usability.

I'd say that I could probably override UNIVERSAL::isa to report that "yes, I am in fact a IO::File". However, the most common idiom these days for determining "isa" is not with a method call, because that fails on non-blessed references. {sigh}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.