in reply to •Re: Re: Say no to ref $thing eq "Expected::Type"
in thread Putting file contents into a scalar

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.

Replies are listed 'Best First'.
•Re: Re: •Re: Re: Say no to ref $thing eq "Expected::Type"
by merlyn (Sage) on Oct 29, 2002 at 19:34 UTC
    {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.

[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.1 Instead it's a way to prematurely embrittle the code.

      When possible I avoid eval for errors which will be immediately handled.2  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]

      1 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!

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

[reply]
[d/l]
[select]
        In your IO::File wrapper you should override isa. Why not? It completes the wrap properly. This is a good argument for isa.
        But you can't. Sorry for not spelling it out earlier, but there's nothing I can do in my wrapper class to make: 
        UNIVERSAL::isa($object_of_my_class, "IO::File")

        [download]
        return true. Yes, I could make: 
        $object_of_my_class->isa("IO::File")

        [download]
        return true, but nobody does that any more because it breaks if the item in question is not a blessed reference. Everyone uses the subroutine form now.

        So, we lose. We all lose. Some place, we've got to push it so it works. I'm saying to do that with either eval wrappers or capability testing with can, not isa.

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

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom