| [reply]
[d/l] |
while(<SOMEHANDLE>)
{
chomp;
my $string = "hello" .$_;
print $string;
}
Still work?
| [reply]
[d/l] |
Yes, still works. That's not explicitly creating a lexical $_.
Here's an excerpt from Perl 5.18.0's "perlvar" (I'm not linking here because perldoc.perl.org hasn't loaded up v5.18 yet.):
$_ is by default a global variable. However, as of perl v5.10.0, you can use a lexical version of $_ by
declaring it in a file or in a block with "my". Moreover, declaring "our $_" restores the global $_ in the
current scope. Though this seemed like a good idea at the time it was introduced, lexical $_ actually causes
more problems than it solves. If you call a function that expects to be passed information via $_, it may or may
not work, depending on how the function is written, there not being any easy way to solve this. Just avoid
lexical $_, unless you are feeling particularly masochistic. For this reason lexical $_ is still experimental
and will produce a warning unless warnings have been disabled. As with other experimental features, the behavior
of lexical $_ is subject to change without notice, including change into a fatal error.
| [reply]
[d/l] |
Off the top of my head, the big ones are:
* Lexical subroutines! package Foo { my sub bar { ... } } Now you can use bar() inside Foo, but there is no way to access that from the outside. There's also state subs, in case you ever seen those.
* Regexp code blocks that actually work! /(?{...})/ and /(??{...})/ now work exactly as you'd expect them to. Before it was a buggy pain.
* Character class set operations! This is my personal favorite. Basically, now you can write /(?[ \p{Math} & \p{Symbol} ])+/ where before you had to do /((?=\p{Math})\p{Symbol})+/. There's other operations too, like + or -.
| [reply]
[d/l]
[select] |