=head2 Lexical C<$_>
The default variable C<$_> can now be lexicalized, by declaring it like
any other lexical variable, with a simple
my $_;
The operations that default on C<$_> will use the lexically-scoped
version of C<$_> when it exists, instead of the global C<$_>.
In a C<map> or a C<grep> block, if C<$_> was previously my'ed, then the
C<$_> inside the block is lexical as well (and scoped to the block).
In a scope where C<$_> has been lexicalized, you can still have access to
the global version of C<$_> by using C<$::_>, or, more simply, by
overriding the lexical declaration with C<our $_>.
If you want to look closer at what it permits, look at t/op/mydef.t.
There are notably two TODO tests, corresponding to until-recently
undocumented uses of $_ (with reverse() in scalar context, and within
/(?{...})/). You're welcome to propose more tests and to find bugs :)
The patch itself is surprisingly small and simple for such a language
change. The Jenga tower has solid foundations :)
I'll need also to silence spurious "masks earlier declaration" warnings
regarding $_ (and to work out how exactly this should be done.)
Some rough benchmarks show that using a lexical $_ is usually faster
than using the global, because accessing a pad is faster than fetching
a GV.
Enjoy.
No, I don't think that this is a good idea for maint :-)
> Some rough benchmarks show that using a lexical $_ is usually faster
> than using the global, because accessing a pad is faster than fetching
> a GV.
But I'm curious whether it's possible feasible to place a reference to
DEFSV in every pad, so that access to the global $_ can be faster.
Or is this a crazy idea? I certainly don't have the knowledge on how to do
it even if it's not totally crazy.
Nicholas Clark
That would be pretty darn unhappy with C<local $_> or C<local *_> (not
that the latter is very important).
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K