Ricardo Signes wrote:
> The last thing I'd said about smartmatch was:
>
> $x ~~ undef
> $x ~~ $overloaded_object
> $x ~~ sub {}
> $x ~~ regex
> ...or fail
>
> ...with when:
>
> when ("foo") # str eq
> when (12345) # num ==
> when ($x) # ~~
> when { ... } # block evaluates true
I discovered a gotcha with that:
given(42) {
when {/4(.)/} {
print $1, "\n"; # prints nothing
}
}
This would need to be documented.
> when breaks the enclosing topicalizer
Define topicalizer. Does it include while(<>)?
>
> I wanted to post that this is a design that would get accepted. The
> reservation of the final case, rather than eq/==, in smart match, lets us
> figure out whether future work on improving num-v-str can be put to work here.
Have you noticed the sprout/smartpatch branch?
I found Smylers’ argument (<20120905143040.GZ1742@stripey.com>) convincing so I implemented it like this:
$x ~~ undef
$x ~~ $overloaded
$x ~~ sub{}
$x ~~ qr//
$x ~~ $anthing_else # fall back to eq
But that makes ~~[] do the wrong thing silently in existing code, so adding this before the last case would improve it:
$x ~~ $other_ref # croak
And when() just does smartmatch.
So now we have three variations. I’m fine with any of them, and they are *really* easy to implement. So which will it be?
Two things I’m not volunteering to do are:
• Coordinate with autodie maintainers about getting it adjusted.
These two files use smartmatch or when:
cpan/autodie/lib/Fatal.pm
cpan/autodie/t/exceptions.t
• Write the documentation (don’t forget to warn about $1 being
unavailable in when {/(1)/} { $1 })
And what do you think of the new whirled order for given/when/last/next on that branch? Also, should break and when produce exiting warnings (they do not currently)?
> On the other hand, there's plenty of reason to give upon given/when/~~, too,
Removing it altogether would be even easier. :-)
> and I think that the one thing we might keep using would be a when-like
> statement:
>
> case (EXPR) BLOCK
>
> equivalent to:
>
> if ($EXPR) { BLOCK <next unless continue> }
>
> That would be a reasonable thing to keep around if we decide we can't get to an
> acceptable smartmatching future.
This does not seem to fit with the subject, so now I really do not know what you are thinking.
Thread Previous
|
Thread Next