On 12/14/06, Joshua Kronengold <[EMAIL PROTECTED]> wrote:
Ronald J Kimball writes:
>On Thu, Dec 14, 2006 at 09:35:57AM -0600, Joshua Kronengold wrote:
>> Shlomi Fish writes:
>> >When I said that $1 may be destroyed by the param method call, he noted
>> >that $1 was locally scoped, which indeed seems to be the case. So my
>> >code should be written like that instead.
>> Wait, what?
>>
>> This seems wrong -- since $1 is locally scoped, (not lexically
>> scoped), it -can- be technically destroyed by the param call, so you
>> don't want to do this, even if you can. (if param is written not to
>> squash $1, it's bad practice to trust in this).
>
>No, it can't be destroyed by the param call. When the param() exits, $1 is
>restored to its previous value, because it is locally scoped.
That's not locally scoped, that's lexically scoped. At least as a
perl-centric coder, locally scoped would seem to be associated with
"local" -- ie, dynamically scoped.
I think we're missing the point here: m// is an operator, not a block.
The behavior it exhibits isn't tied to the scoping of the variables it
employs.
$1 is dynamically scoped. Subroutines declared anywhere will be able
to see their caller's $1. This is both demonstrably true and clearly
stated in perlsub and elsewhere.
[snip]
>I'm not sure what you're trying to show with that code.
That my assumptions were wrong? I remember "losing" $1 due to
subroutine calls with perl 5.003 or so, but clearly the implementation
has changed.
This has very little to do with scoping, and very mush to do with the
behavior of the operator. The regex engine, apparently, now
dynamically scopes match vars for every invocation. Think of every
invocation of m// no beginning with something like 'local $1 = $1'.
This was not (consistently?) the previous behavior, but it's the
interface that's changed, not the scope, or, more importantly, the
type of scope.
>Here's an example
>that shows that $1 is locally, not lexically, scoped:
...
>{
> /(a)/;
> print "$1\n";
> foo();
...
>sub foo {
> print "$1\n";
>If $1 were lexically scoped, the value it gets within the block wouldn't be
>visible in the subroutine, which is outside the block.
Exactly.
Ah. So what you are actually saying is "Match operators localize $1"?
No. what he's saying is that you can't determine whether a sub is
seeing dynamic or lexical variable from the value of the variable
after the sub. These two bits of code will produce exactly the same
results:
{
local $aa = 1;
{
local $aa = 2;
}
print $aa;
}
{
my $aa = 1;
{
my $aa = 2;
{
print $aa;
}
That's very different than "is locally scoped", and much clearer, but
I'd prefer people didn't use the latter; it's as misleading as saying
"$_ is locally scoped".
And wrong. $1 is "locally scoped," or, more properly, dynamically
scoped, which should clear up and confusion.
(the latter being both not true (most constructs that override $_
automatically actually alias it to something else -- which I assume
involves pushing the reference to something else onto it's stack, and
which is similar, but not identical to localization), and not
universally relied upon (see while(<>)).
Again, what most constructors do has noting to do with whether the
variables they inherit are lexically or dynamically scoped. $_ is in
fact dynamically scoped. There's a failsafe litmus test here: try
calling my and local on any variable you're unsure of. One or the
other operator will fail with either "can't use global _ in 'my" or
"can't localize lexical variable". If you're ever in doubt about a
variables scope, just try to localize it.
HTH,
--jay
--------------------------------------------------
This email and attachment(s): [ ] blogable; [ x ] ask first; [ ]
private and confidential
daggerquill [at] gmail [dot] com
http://www.tuaw.com http://www.downloadsquad.com http://www.engatiki.org
values of β will give rise to dom!
