> Date: Wed, 13 Nov 2002 20:34:49 +0000
> From: Nicholas Clark <[EMAIL PROTECTED]>
>
>
> If a subroutine explicitly needs access to its invocant's topic, what is so
> wrong with having an explicit read-write parameter in the argument list that
> the caller of the subroutine is expected to put $_ in?
>
> It makes it clear.
>
> If I understand all this correctly, as is, this "access caller's topic"
> is an unrestricted licence to commit action at a distance.
>
> Accessing the caller's topic is the default in perl5. And there is still a
> steady stream of bugs to p5p where core perl modules are doing something
> (typically a while loop) which tramples on $_, and so makes something go
> wrong in their caller. (possibly several levels down)
>
> (And for that matter the "obvious" solution of local ($_) in perl5 is also
> action at a distance if $_ is tied, as local is an immediate fetch and a
> store at end of scope. Special case local on $_ ?)
Indeed. And also mind that many (IIRC all, but I could be wrong)
Perl5 builtins used $_ as the I<default>, and if a parameter was
supplied it would use that.
My favorite was from ages ago:
sub bar(;$foo //= $_) {...}
'Course that could be mistaken for defaulting to the current $_ in
C<bar>'s lexical scope. Regardless, IMO it is better style to always
use $_ as just a default, rather than a requirement. Is there a good
reason to have subs like this:?
sub bar($foo) is given($baz) {...}
Or, if you stick with Perl5 convention, and I imagine this is what
people will expect from the builtins at least:
sub bar($foo; $baz) is given($baz) {...}
That duplicated parameter looks strange, and people will be wary of
using it that way (as I was). I don't know what it looks like, but it
doesn't look like $baz gets $_ if not, well, C<given>.
Luke
