: The invocant is bound to both.
Hmmm. I'm not so sure. I can argue it both ways. Sure, it's nice to be able to attach an absolute rule to "method", but I'm inclined to think that unsigged methods work a little more like Perl 5 in that case, and just put the invocant (or rather leave the invocant) in @_[0]. This might simplify the translator. But if were just methods, I'd wouldn't make an exception.
But I'm wondering if there is another general rule that supercedes method topicalization. We could have a policy that all *sigless* sub declarations just treat $_ as an external lexical variable, rather than the A6 policy of implicitly declaring an undefined $_. This would have the beneficial effect (from the standpoint of p5-to-p6, anyway) that most sigless subs default $_ to file-scoped $_, and a great deal of the Perl 5 code that treats $_ as dynamically scoped would still work, as long as the caller and callee were sharing the same file-scoped $_.
> > 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.
I specifically avoided "type" or "kind" because I didn't want to imply mere type matching when something more general might be happening, such as smart matching, of which type matching is a small subset.
So maybe $which would be better???
Damian
