On Wed, Mar 19, 2003 at 01:07:32PM +1100, Damian Conway wrote:
: Larry wrote:
: > A file-scoped $_ could be considered a sort of a half-way house to full
: > signatured $_ semantics. You couldn't clobber some other module's $_,
: > but you still get a dynamically scoped $_ where naive users expect it.
: >
: > It's not a beautiful solution, but it might make the migration a lot
: > smoother. Something to be said for that...
: : Isn't that still going to break most translations? I mean, if a Perl 5
: method (that's being translated to Perl 6) refers to $_, it surely means : $CALLER::_, not $OUTER::_. So Perl 6 calls to it (typically from a : different file scope) won't provide the expected $_ anyway.
Most of the people treating $_ dynamically are doing it with subs and not methods, I suspect. That's where the policy is aimed.
I must be missing something here. I still don't see how this can work. I mean, if I write:
module Foo;
sub foo1 {
print "foo1: [$_]\n";
} sub foo2 is exported {
print "foo1: [$_]\n";
}__END__
Then, if I'm understanding correctly, those two $_ within the subs
would not be lexically scoped to the subs, but would be the implicit filescoped $_.
But that doesn't seem to help when I later use that module in another file:
use Foo;
given 'bar' {
foo1(); # prints: foo1=[]
Foo::foo2(); # prints: foo2=[]
}and get two nasty "undefined value in string interpolation" warnings as well. :-(
Damian
