Front page | perl.perl6.language |
Postings from February 2002
Of course, this idea may have already been considered and rejected, in
which case I'm just curious to learn the reasons.
What would be the cost (performance, design or dwim) of making all the
defaulting constructs pay attention to the current topicalizer in
preference to $_?
C<when> is beautifully dwim, testing against the topicalized value (the
given) when there is one and $_ when there isn't. It seems like it might
be useful if C<print>, C<chomp>, C<s///>, etc. behaved the same way.
given $foo -> $bar {
when /something/ { # matches against $bar
chomp; # also on $bar
s/this/that/; # also on $bar
print; # prints $bar
}
}
I like the idea of being able to say "defaulting constructs always obey
the lexical scope of topicalizers".
For the most part, the change would have no impact on current code.
Examples that use $_ would still behave the same, as $_ is the
topicalized value anyway:
for @foo {
s/this/that/; # substitute on $_
...
}
Examples that use an aliased named variable would also work as-is, they
would merely have the option of simplifying:
for @foo -> $bar {
# $bar =~ s/this/that/; # still works
# print $bar;
s/this/that/; # would do the same thing
print;
...
}
There are problems with embedded topicalizers. Someone might
intentionally use the fact that the $_ of the outer topicalizer is not
clobbered by the aliased named variable of the inner topicalizer
($nonsense), and use a defaulting construct on $_ within the embedded
scope.
for @foo {
s/this/that/; # on $_
for @stuff -> $nonsense {
s/that/another/; # currently on $_,
# on $nonsense with change
...
}
}
Since it can be done, I'm sure the Perl 5 counterpart of this exists in
some code somewhere. And even if $_ is officially "just another lexical"
it still seems uncomfortable to have to code:
$_ =~ s/that/another/;
This may be a tolerable discomfort. I'm not sure. Using a second aliased
named variable would also work, and has the advantage of making it more
obvious (to the human eye) exactly which variable was matched against,
especially within numerous levels of embedded topicalizers.
for @foo -> $bar is rw {
for @stuff -> $nonsense {
$bar =~ s/that/another/;
...
}
}
If you wanted to set up a context in which a particular value was the
default, instead of assigning the value to $_, you could wrap the code
in a C<given>.
# Actually, this should already work, because $_ is
# aliased to the value of $foo.
given $foo {
chomp; # on $_
s/this/that/;
print;
}
# This would have the same effect.
given $foo -> $bar is rw {
chomp; # on $bar
s/this/that/;
print;
}
Is it an abuse of C<given> to use its abilities as a topicalizer outside
the context of a switch statement? Well, possibly, but an interesting
one. :)
Simply pondering,
Allison
Thread Next