in reply to Re^4: Control Structures
in thread Control Structures

If you think it's that obvious, you're not getting it. Here's some code that demonstrates how this can bite you: 
sub sticky {
   my $arg = shift;
   my $object = Some::Package->new() if $arg;
   $object ||= Other::Package->new();
}

[download]
The first time you run it with $arg = 0, you will get the expected result. The second time through with $arg = 0, you will find the Other::Package object from last time in $object and it will not get a fresh Other::Package object assigned to it. So, if you never put anything in $object when the conditional is false, you won't actually see the bug.

I have personally seen people lose days debugging problems caused by this, and have heard stories about it happening in other companies too. It's hard to see, it's very hard for people to fully understand, and it really happens in production code.

Replies are listed 'Best First'.
Re^6: Control Structures
by glwtta (Hermit) on May 12, 2005 at 05:26 UTC
    I understand how the problem manifests itself, it's not rocket science after all.

    What I am saying is that if I want this: 

    sub foo {
   my $arg = shift;
   my $object = ($arg) ? Some::Package->new() : Other::Package->new();
}

    [download]
    It seems blindingly obvious that the snippet you provided is not the way to go about it. I agree that the compiler should warn you about this (or better yet, disallow it entirely); it just seems that if someone has trouble with this, the problem probably lies with understanding 'my', not confusing if() syntax.
[reply]
[d/l]
      "Blindingly obvious"? Your change looks like a tiny style nudge, not the difference between working and broken. It doesn't surprise me at all that people trip on this.
[reply]

In Section Meditations