At 09:10 AM 2/8/2006 -0800, Glenn Linderman wrote:
>So, $lTokens is a reference from a sub, to a variable declared outside
>of the sub (specifically, to the $lTokens declared in parse on its first
>invocation), thus making gettoken a closure.... and causing that
>instance of $lTokens to be preserved as part of the state of the closure.
Eh, I don't see how this case is a closure. Closures deal with anonymous
subroutine references. The gettoken sub is declared normally except for the
fact that it's declared within another sub (which should be illegal IMHO).
Closures keep otherwise scoped data alive by holding open references to the
data.
However, this seems to be acting just like a closure. It could be that perl
thinks that anything sub{my; sub{}} is a closure. Which I would consider a
bug. According to O'Reilly, nested named subroutines don't work and are
"wrong".
Quote:
[7]To be more precise, globally named subroutines don't nest.
Unfortunately, that's the only kind of named subroutine declaration
we have. We haven't yet implemented lexically scoped, named
subroutines (known as my subs), but when we do, they should nest
correctly.
So it seems that currently, sub { sub gettoken {} } is identical to sub {
$gettoken = sub {} }.
--
REMEMBER THE WORLD TRADE CENTER ---=< WTC 911 >=--
"...ne cede malis"
00000100
_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
