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.

In your IO::File wrapper you should override isa. Why not? It completes the wrap properly. This is a good argument for isa.

Are they grinding you down today? Reusability is based first on usability. Ensuring that good code will interface with the most lousy code possible may be efficacious, but it is not maximizing reusability.¹ Instead it's a way to prematurely embrittle the code.

When possible I avoid eval for errors which will be immediately handled.²  So to check if a param can do something, if it even is a blessed thing I'd use these terms in some conditional:

ref $it and $it=~/=/ and $it->can($meth) and $it->$meth();
[download]

---

¹ Having the largest user base doesn't mean the code is more reusable. The word "pandering" begs usage here. It's like that. Stop it, go 'way. Bad word!

² The "throw" analogy for exceptions is appropriate: raise an exception when you can not handle the problem locally.