On Wed, Nov 13, 2002 at 08:34:49PM +0000, Nicholas Clark wrote: > 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's the difference between this:
print;
and this:
print $_;
It is as far as I'm concerned exactly what topic is all about. It let's
you write subroutines that behave like builtins with respect to $_. I
think it's generally intended to be used like so:
sub my_print is given($default) {
my @args = @_ // $default;
...
}
i.e. only doing stuff with $_ if no explicit parameters are passed.
> 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)
I don't think that'll be a massive problem with this. It's not the same
thing at all because $_ is now lexical it's not passed to stuff you call
unless it specifically asks for it. This will eliminate the trampling
over $_ several levels down. Needlessly messing with caller's $_ will
become like not using strict or warnings. Occasionally useful but
generally frowned on in a "don't do that" kind of way.
andrew
--
Gemini: (May 21 - June 21)
Disappointment is yours when you overestimate the power of the
human spirit.
msg12018/pgp00000.pgp
Description: PGP signature
