Front page | perl.perl5.porters |
Postings from August 2012
On Thu, Aug 23, 2012 at 3:50 PM, Leon Timmermans <fawaka@gmail.com> wrote:
> You're proposing that:
>
> any(9,10,11) ~~ \&is_prime
>
> be equivalent to:
>
> is_prime(any(9,10,11))
>
> but what if I want it to mean what it's supposed to mean:
>
> any(is_prime(9), is_prime(10), is_prime(11))
If «is_prime(any(9,10,11))» is not equivalent to «any(is_prime(9),
is_prime(10), is_prime(11))», it's not a junction in the first place.
I think you're actually in violent agreement. :-)
My view: overloading should take precedence over all other match types
because an object might need to present itself differently depending on
what's on the right hand side and thus needs to be able to supersede other
comparisons.
Stepping back -- look at what 'perldoc overload says':
How Perl Chooses an Operator Implementation
Which is checked first, "nomethod" or "fallback"? If the two
operands of an operator are of different types and both overload
the operator, which implementation is used? The following are
the precedence rules:
1. If the first operand has declared a subroutine to overload
the operator then use that implementation.
2. Otherwise, if fallback is TRUE or undefined for the first
operand then see if the rules for autogeneration allows another
of its operators to be used instead.
3. Unless the operator is an assignment ("+=", "-=", etc.),
repeat step (1) in respect of the second operand.
4. Repeat Step (2) in respect of the second operand.
5. If the first operand has a "nomethod" method then use that.
6. If the second operand has a "nomethod" method then use that.
7. If "fallback" is TRUE for both operands then perform the
usual operation for the operator, treating the operands as
numbers, strings, or booleans as appropriate for the operator
(see note).
8. Nothing worked - die.
Where there is only one operand (or only one operand with
overloading) the checks in respect of the other operand above are
skipped.
There are exceptions to the above rules for dereference
operations (which, if Step 1 fails, always fall back to the
normal, built-in implementations - see Dereferencing), and for
"~~" (which has its own set of rules - see "Matching" under
"Overloadable Operations" above).
What we're talking about is removing the special case for ~~ and making it
work just like other operators. Since smartmatch has no autogenerated
fallback and is not an assignment, the table above collapses to something
essentially similar to what Damian described *except* that he suggests
making right side overloading take precedence over the left side.
And to that -- why? Should it be completely consistent instead, where
overloading on the value being tested (left side) takes precedence over
overloading on the comparison value (right side)?
Presumably, overloading on the value would be due to it replacing the
object with a different value to actually compare and would then smartmatch
on the replacement value against the original comparator -- which would
then trigger the overloading on the comparator and do the right thing.
On the contrary, overloading on the comparator might result in a different,
non-smartmatch comparison being performed. That might trigger different
overloading on the value (e.g. "eq" or "=="), but would bypass smartmatch
overloading. That seems likely to lead to bugs by incautious overloaders.
Removing special cases is *good*. Let's make smartmatch overloading work
just like other operators.
David
Thread Previous
|
Thread Next