The obvious extension to given <value> is given <list>, as:
given $foo -> $bar is rw, # I think this is more readable
$moo -> $baz is rw
{
...
}
or
given ($foo, $moo) -> ($bar is rw, $baz)
{
...
}
What would the default-variable scheme do in this context?
(Please, no-one suggest nesting 5 or 6 of these.)
=Austin
--- Allison Randal <[EMAIL PROTECTED]> wrote:
> 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
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
