On Fri, 2006-07-14 at 00:08 +0300, Yuval Kogman wrote:
> Also, sometimes i am matching on behalf of my caller, this is very
> common in dispatch algorithms, or things like tree visitors:
>
> my @list = $tree.filter_children( $match ); # very generic and useful
It's really the fact that that's a method that hoses everything. There's
essentially no way to compile-time dispatch that, so even macros won't
help you.... grr.
No, you've got me. There needs to be a way to do that, but oh dear it's
going to be confusing, and as ever, I worry about those who will use
this sort of thing poorly or mistakenly, and then rant on about how Perl
is write-only.
Perhaps the solution is not code, but documentation. Perhaps if we make
a clean break between comparison and matching in the docs, and push
people away from non-regex/string-~~ until they understand its
implications, we can head off much of the lossage.
For example (modified S03 "Smart matching" section without the table):
=head1 Smart matching
Smart matching is the process of asking, does thing I<a> conform to the
specification of I<b>? The most common reason to want to do this is to
match a string against a regex:
if $s ~~ /^\d+$/ { ... }
But smart matching is also performed by given/when for switch-like behavior:
given $s {
when 'Apple' { ... }
when 'Pear' { ... }
default { die "No fruit!" }
}
Notice that the specification can also be a string, as above, but because
C<eqv> and C<~~> mean the same thing in this context, it is clearer, when
writing a single expression to explicitly use C<eqv>:
if $a eqv $b { ... }
The right-hand side of C<~~> (the specification) always controls the
nature of the matching, so care must be taken when matching. Do not
think of this as simple "comparison" where the arguments are considered
peers.
Here is the current table of smart matches with respect to $_ and $x
as they would be used here:
given $_ {
when $x {...}
}
or
$_ ~~ $x
The list is intended to reflect forms that can be recognized at
compile time. If none of these forms is recognized at compile time, it
falls through to do MMD to C<< infix:<~~>() >>, which presumably
reflects similar semantics, but can finesse things that aren't exact
type matches. Note that all types are scalarized here. Both C<~~>
and C<given>/C<when> provide scalar contexts to their arguments.
(You can always hyperize C<~~> explicitly, though.)
Both C<$_> (the value) and C<$x> (the match specification) here are
potentially references to container objects.
And since lists promote to arrays in scalar context, there need be no
separate entries for lists.
(table goes here)
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback
