in reply to Re: Re^2: (nrd) Putting file contents into a scalar
in thread Putting file contents into a scalar

And the additional benefit to be able to test for the type of a scalar which happens to be passed to me, by checking for ref $fh eq 'IO::File'.
Please don't do that. Your code is fragile. It will break when I pass an object that subclasses IO::File but acts in every way like an IO::File.

Instead, write your code so that the class doesn't matter. Use the polymorphism as it was intended. If you are unsure if $object_x can handle a particular method call, then use UNIVERSAL::can against it, or put it in an eval block to trap the potential error.

The use of ref in ordinary code should be limited to determining whether something is a reference or not (such as whether the first parameter for a method call is a class or instance). Any explicit comparison will break subclassing. Too much "navel contemplation" is a bad thing in robust code.

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

  • Comment on Say no to ref $thing eq "Expected::Type"

Replies are listed 'Best First'.
Re: Say no to ref $thing eq "Expected::Type"
by Felonious (Chaplain) on Oct 29, 2002 at 14:44 UTC
    or use UNIVERSAL::isa() which will most easily accomplish what merlyn is talking about.

    [TINPC@perlcabal.com shh]$ su real
[reply]
      No, I meant "can" specifically.

      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.

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

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom