On Sat, Apr 13, 2002 at 08:53:41AM -0700, Glenn Linderman wrote:
>
> 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.
> ...
I agree dynamic scoping of $_ in subroutines by default would make for
an easier transition between 5 and 6. And at first I preferred it.
But I'm gradually leaning in the opposite direction. The lexical scoping
of $_ encourages encapsulation (good coding practice), and minimizes
unexpected side effects.
> 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.
I think the two most confusing aspects of $_ in 5 are the fact that it
isn't created consistently (only when there isn't a named alias) and how
easy it is to accidentally clobber it. Both of which should be
eliminated in 6. :)
> 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.
Yeah, any of the properties or //= should work on any parameter in the
list.
> 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.
Well, "topic_preserving" wasn't intended as a defaulting mechanism, just
as a way of keeping the value of $_ across subroutines, even though it's
lexically scoped. That's why I prefer the subroutine property, it makes
it clearer that we're fundamentally altering the behaviour of
subroutines, instead of making it look like we're just monkeying around
with the parameters.
For defaulting to the current topic, I'd probaly choose a property name
"topic_default" instead.
Possibly it would be helpful to be explicit about the options we're
discussing:
sub foo ($bar //= $_, ...
The parameter can be passed a value, but it will default to the outer $_
if not passed a value. It will not set the value of $bar as topic within
the subroutine, so the inner $_ will be undefined (unless there was a
global $_ defined, which would produce really anti-dwim behaviour). One
thing to consider here is that we're already abusing the "$_ is lexical"
concept to make the $_ of the calling scope accessible as a value for
the parameter.
If you wanted to also make $bar the topic within the sub, you'd have to
use the property C<is given>:
sub foo ($bar //= $_ is given, ...
So, the C<is topic_default> property would condense the two behaviours
into one. I would guess that if you've defaulted to $_ you would expect
it to also be $_ within the sub anyway.
sub foo ($bar is topic_default, ...
It also makes it clearer that this isn't your ordinary //= default
happening, but a special lexical scope bending one.
The other proposed property, C<is topic_preserving>, wouldn't accept a
value passed in, it would only and always be the $_ of the calling
scope, and make it the topic within the subroutine scope.
sub foo ($bar is topic_preserving, ...
Okay, looking at the details laid out like this, I would probably ditch
the "topic_preserving" property in favor of "topic_default".
But "topic_default" isn't going to give us perl 5 behaviour. Neither
would "topic_preserving", because both alter the parameter structure of
the sub.
So, my favorite final solution: Use the subroutine property
"dynamic_topic" for perl 5 behaviour, "topic_default" to create C<print>
type subs.
> 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 ???
I'd say a bug. I don't know, can you:
sub foo ($bar //= $some_value //= 3, ...
(Presuming that $some_value is a true global or otherwise accessible in
the scope where the sub was defined.)
If you can do that, then it should probably work the same for $_
defaulting.
Allison
