in reply to Is "ref($class) || $class" a bad thing?

This function call passes nothing:

my $foo = Foo::new();

What do you expect to be in $class in this code?

sub new {
  my ($class) = @_;
  $class = ref($class) || $class;
  return bless {}, $class;
}

[download]

What do you expect to be in $class in this code?

sub new
{
    my $class = shift;
    bless {}, $class;
}

[download]

I don't see the connection.

Replies are listed 'Best First'.
Re^2: Is "ref($class) || $class" a bad thing?
by kscaldef (Pilgrim) on Jul 12, 2004 at 17:19 UTC

    The point, such as it is, is that in order to cover all three possible evaluations of the conditional, you have to make that meaningless call. This, of course, sucks. Now, probably the answer is that 100% code coverage isn't always possible or desirable.

    On the other hand, I've seen large (hundreds of classes) systems where every constructor included ref $class || $class, and nowhere was any of them ever called using an existing instance. So, that's just silly.

    If you never use the constructor in this way, you might as well just drop it. As a minor side-effect, you get your code coverage a little higher, and maybe that makes your manager happy or something.

[reply]
[d/l]
Re^2: Is "ref($class) || $class" a bad thing?
by stvn (Monsignor) on Jul 12, 2004 at 17:24 UTC

    I am not sure I understand your point. I think you are trying to say that 

    $class = ref($class) || $class;

    [download]
    is no better/worse than 
    my $class = shift;
bless {}, $class;

    [download]
    which is quite true, and since that is also a common idiom which will produce the same issue, then maybe that is not so good either.

    In all cases, $class is undef, and when bless is passed undef it blesses into main. It might (and I stress might, because I am not so sure of this) make sense if when bless encountered undef in its second argument, that it treated it as a one-argument bless instead (which would result in blessing into the current package).

    -stvn
[reply]
[d/l]
[select]

      I'm suggesting (as I think your conclusion supports) that if you have to abuse your API to test the possibilities that your code should support, you have a mismatch somewhere.

      There are reasons to call methods as subroutines in tests, but those are rare. If you've not violated Liskov substitutability, you can probably subclass appropriately. (If you have violated LSP, you should rethink your design. :)

[reply]
        I'm suggesting (as I think your conclusion supports) that if you have to abuse your API to test the possibilities that your code should support, you have a mismatch somewhere.

        Well, if you want to support Foo::new() then it would not be abusing the API, it would be testing a feature. If you want to punish those who abuse your API, then I think it is appropriate to test it for the error/exception.

        However, if test it because you just want 100% coverage, then you probably just need to relax.

        I guess my feeling is that I want to punish those who abuse my API, maybe that is not so perl-ish, and maybe its a little control-freaky, but I like knowing that my module will perform as expected under both intended and unintended conditions.

        -stvn
[reply]
[d/l]

      Would $class = ref($class) || $class || __PACKAGE__; make it work in that case?


      ___________
      Eric Hodges
[reply]
[d/l]
        How does that fix Foo::new( {} )?

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]
[d/l]

In Section Meditations