Allison Randal wrote:
> What if $_ were dynamically scoped, but only for subroutines? Dynamic
> scoping is not necessarily the same thing as a global $_. It would
> merely pretend (only for $_) that the subroutine had been defined in the
> scope where it was evaluated. But that could get you into trouble with
> recursion. So then you would want some way to explicitly either turn on,
> or turn off, dynamic scoping for a specific subroutine. The C<is given>
> (or C<is topic>) property would be an obvious way to turn it off (since
> it would create a $_ scoped to the subroutine). But, what if you wanted
> it off by default? It could be turned on either as a characteristic of
> the sub as a whole, or as a characteristic of an individual parameter:
>
> sub foo is dynamic_topic {
> ...
> }
>
> sub foo ($bar is topic_preserving, $baz) {
> ...
> }
>
> The property C<is topic_preserving> would be both binding the value of
> the $_ in the calling scope to $bar and making $bar the current topic in
> the scope of the sub.
>
> The subroutine property would be basically the same, but wouldn't give
> you a named variable, and also wouldn't require you to include an extra
> parameter (which could be nice).
OK, I can see how all these things could work. Off hand, it seems like
defaulting to "is dynamic_topic" would make more of those common useful
$_-dependent subroutines work without change, but I guess if the perl 5
to 6 translator can detect use of $_ before definition of $_ within a
sub accurately, that it could provide the appropriate annotation during
conversion. And personally, I haven't written subs that assume dynamic
$_ usage (I think), so I'm not too concerned about which way the default
goes. I'm not a real heavy user of $_ for everything, as some people
seem to be. It's useful at times, but can also be confusing at times.
Regarding is topic_preserving: I assume that it would not have to be the
first parameter; it would generally be more useful as the last, I
expect, as in split, or the first optional parameter. Of course, there
are cases where first and last are the same, or the other parameters can
also be usefully defaulted when the first one is, etc.
There'd be an interaction between is topic_preserving, default parameter
values, and explicit parameter values which should be clarified. Now I
understand why someone suggested using //= $_ instead of is
topic_preserving, somewhere along the line. Clearly if the user
supplies the parameter, is topic_preserving would limit itself to making
that parameter available as $_ within the sub. If the user supplied
both //= 3 and is topic_preserving, that would either be a bug or a
feature. I guess as a feature, it would use $_, but if $_ were undef,
then it would use 3 ???
--
Glenn
=====
Remember, 84.3% of all statistics are made up on the spot.
