On Wed, Feb 27, 2002 at 04:24:48PM -0600, Garrett Goebel wrote:
> From: Allison Randal
>
> Not just some value external to the switch, but the value in $_.
>
> I now see the DWIM aspect. Thanks BTW.
>
> But how often will people have non- C<when> statements within a C<given>
> scope that'll need the special case handling so they can see a different $_
> than C<when>?
That's exactly what the non- C<when> statements will see currently.
Are you asking the question in the context of Apocalypse 4 or in the
context of the hypothetical "C<when> aliases to $_" discussion? I'll
answer as if the former, because it seems to fit the best, but if you
meant the latter the answer would be slightly different.
I think we're bogged down in the "$_ is default" idea. We really have
two entirely separate defaults, $_ and topic. Sometimes they're the same
and sometimes they're not. Hmmmmm... pretend for a moment that there's a
variable $topic (there isn't, but pretend). It's very similar to $_, but
not quite. When you do a
given $x {
...
}
then both $_ and $topic hold the value of $x. But, when you do a
given $x -> $y {
...
}
$topic holds the value of $y (i.e. the value of $x), but $_ doesn't (it
hasn't been affected at all).
C<when> always defaults to $topic, it doesn't care about $_ (except that
when $topic has no value at all, it will "steal" a value from $_). But
everything else still defaults to $_, and pays no attention to $topic.
(And remember, there is no $topic, it is merely for illustrating the
existence of the abstract "topic").
So this is what the code would be doing:
> $hi = 'hello';
> $x = 'burt';
> for $hi {
> given $x -> $y {
> when /burt/ { print "Go Away" };
# matches on $y, the topic
> default { print };
# prints $_, not $y
> }
> }
>
> or without the special case:
>
> $hi = 'hello';
> $x = 'burt';
> for $hi -> $y {
> given {
> when /burt/ { print "Go Away" };
> default { print $y};
> }
> }
The second bit of code (with corrections in place) isn't going to do
what you expect at all because the
given {
...
}
is an "empty given" which has a special meaning of "make boolean
comparisons". So /burt/ is being compared to "True" (I'm not sure if
this would fail because the regex doesn't match "True", or succeed
because "burt" is a true value, but it wouldn't have anything to do with
$y).
> The second is obviously more explict, but does but requires a few more keys
> be typed. I wonder if the C<given>/C<when> special case is really going to
> be used regularly enough to justify the loss of clarity, consistency, and
> the additional obfuscation potential.
>
> $_ = 'foo';
> given 'bar' -> $z {
> if /foo/ { ... } # true, $_ = foo
> when 'bar' { # true, $_ = bar
> if /foo/ { ... }; # true, $_ = foo
> }
> $_ = 'baz'; # $_ = baz
> when 'bud' { # false, $_ = bar
> if /baz/ { ... }; # true, $_ = baz
> }
> }
So these lines are not "$_ = bar" but
...
when 'bar' { # true, topic = bar
...
when 'bud' { # false, topic = bar
...
I think your more general question boils down to: "Is this whole notion
of topic really worth the effort"? And the confusion about C<when>
actually supports your argument. Perl gurus and newbies alike are going
to have to do a little mental stretching for this one (just a tiny bit).
But I do think it's worth it. Despite the details of consistency and
clarity that still need to be worked out, it's a very dwim change that
is a big part of the elegance of the switch statement.
> I guess the next question in the context of the following is:
>
> Larry Wall wrote in Apocalypse 4:
> > It should be possible to make user-extensible syntax look
> > just like built-in syntax.
>
> How would I create a user-extensible construct that works like given/when?
> I'm guessing the answer is: you don't.
I sure hope you can. I intend to use it.
Allison
