in reply to Are we seeing syntax inconsistency?

In your second example, the inconsistency between the button text and the sub is because of a difference in when the code is executed. When you call $mw->Button, the code you have in your constructor call is run right then, so "Button $_" is converted to a static string, and Button saves a copy of that static string somewhere, so even if $_ changes the button's text stays the same. But the anonymous sub you give as the argument to -command isn't executed until the button is clicked. By then the value of $_ will probably have changed, and so the sub will use the current value of $_ instead of its value when the constructor was called.

As others have said, your first example uses a closure, which implicitly creates a copy of the variable when the anonymous sub is created, so the sub refers back to that variable. Closures keep lexically-scoped variables (those created with my), but $_ isn't lexically scoped. That's the key to the difference between the two.

You could also solve the problem by forcing the anonymous sub to resolve $_ when it's created, using eval: 

  -command => eval "sub {print $_}"

[download]
(n.b. I haven't tested this and it might not be exactly right). But using closures is much easier, faster, and more elegant.

Replies are listed 'Best First'.
Re^2: Are we seeing syntax inconsistency?
by Aristotle (Chancellor) on Nov 11, 2005 at 17:56 UTC

    No, that doesn’t work in the general case. It would work here, because the string which eval sees is, say, sub { print 0 } on the first iteration. But if the loop was for( "foo bar", "baz quux" ) ){ ... }, then the eval would incorrectly be called to compile sub { print foo bar }, which may fail to compile or may compile to nonsense.

    You want to stick the value in a lexical and close over the lexical. That is the correct general solution.

    Makeshifts last the longest.

[reply]
[d/l]
[select]
      Right, I gave that as an example to clarify what's going on, not a recommendation. Though I think it can be made to work in the general case with judicious use of quotes and quotemeta. :)
[reply]
[d/l]

        You mean something like eval qq{ sub { print "\Q$_\E" } }? Not what I think of as a pretty solution, since you’re firing up the compiler (and repeatedly) at runtime, but yeah, that would do it.

        Makeshifts last the longest.

[reply]
[d/l]

In Section Seekers of Perl Wisdom