Re: This is really a Perl BUG with my?! Need some advice...

[thelenm]

in reply to This is really a Perl BUG with my?! Need some advice...

There have been some enlightening discussions of this "feature" on PerlMonks before... check these out:

• Unusual Closure Behaviour
• It *is* a feature: mod_perl and 'my $x if 0'
• static-like persistence of my variable due to trailing conditional

[duff]

In particular, read Abigail's response to Unusual Closure Behavior. It's a good, concise explanation.

[gmpassos]

Thanks for the nodes. But I think that this is a bug, specially because is hard to understand why it happens!

Note that the nodes that you have pointed use $x if 0 ; just to declare the variable, but without clean it after go out of the scope. But here I'm using my $x = 123 if $foo ; to set or not he variable already declared. (At least this is a difference of purposes).

Soo, the different behavior is not in the declaration or set of the variable, but what happens when it goes out of the scope block! And This is documented as a resource or valid syntax? I think that not.

And if someone really want a variable that remembers it's value, it just delcare it in the top of the package, not in the sub!

For me this is a bug, and was found because it causes bugs in the output of my code!

[chromatic]

What would you expect this code to do?

if ($foo)
{
    my $bar = 1;
}

print $bar;

You're doing the same thing without changing scope. Sometimes you ask Perl to create a new lexical in the pad, sometimes you don't. Since the sub reuses its pad between invocations and since destroying and recreating all lexicals in a pad is an expensive operation, if the my doesn't fire, you end up reusing the previous variable.

Update: Highlighted the important bit that I'd already explained.

[gmpassos]

No, this is not the same thing! Try to use strict to see.

[jonadab]

my $local = "[$n] set" if ($n/3) !~ /\./ ;

Really your problem here is that you've misunderstood precedence. Try it this way:

my $local = ((($n/3) !~ /\./) ? "[$n] set" : "");

Now, about this being a bug...

But I think that this is a bug, specially because is hard to understand why it happens!

A lot of people who haven't seen closures before think it's hard to understand why closures work the way they do -- does that make them a bug? Continuations are even weirder and harder to understand. Perl5 doesn't have them, but Scheme considers them important, and I think we're getting them in Perl6. Will they be a bug if you don't understand them?

A bug is when the compiler/interpreter/whatever does something different than what it's *intended* to do, not when you don't understand the reasons behind why it's doing what it's doing.

Now, in this particular case, davido has pointed out that the behavior is undefined. I personally feel that the mere existence of undefined behavior is a Bad Thing(TM), and that a language should nail down the behavior of everything that's not a syntax error. However, that's a philosophical position I have, a design issue -- failure of Perl to do that is a design choice (albeit one I disagree with), not a bug. chromatic's note makes me suspect it was left the way it is for reasons of efficiency -- another design choice I personally disagree with (I always favour robustness and definedness over optimization), but nevertheless a design choice, not a bug. perl is doing what it was intended (by the people who created it) to do.

So filing a bug report is unlikely to have any useful effect.

[gmpassos]

...I personally feel that the mere existence of undefined behavior is a Bad Thing(TM)...

This is why I think that is a bug!

And I don't thin that this is classified as a closure, since the variable is defined in it's own scope, not outside of it. Soo it can't close what it delcare for it self! This is just a persistent scope variable. But in the end is all the same thing. I just don't think that is a closure because it's not stealing a variable from other scope, but from it self.

And I really think that this behavior should be removed, at least we need to start with the warnings from now.