Front page | perl.perl5.porters |
Postings from August 2012
David Golden suggested:
> But the semantics of LHS and RHS are different because smartmatch is
> non-commutative.
>
> For a LHS object, the only semantically correct thing to do is to transform
> one's own value and smartmatch it against the RHS comparator (or possibly a
> suitable transformation of it [1]).
True. At least: "often true".
Except that the algorithm to do the actual matching may need to remain
non-standard.
For example, consider the LazyString class or the DNASeq class, both of
which pull (pieces) of insanely big strings in from memory. You can't just
provide them with a q{""} overloading and let the built-in smartmatch
semantics handle that. The very reason you're using those classes is
to avoid having to assemble the entire string in memory (which an
overloaded q{""} would have to do). So you need the LHS overloaded-~~
to provide the entire "piecewise" matching semantics, no matter what's
on the RHS.
> Whatever it does, it *must* give the LHS a chance to trigger its smartmatch
> overloading. (Requiring a subroutine is also inefficient.)
Sure. Whenever there are objects on both sides of the smartmatch, we're
going to have to double-dispatch on them both, no matter what.
> Thus, since a proper RHS overload must trigger a LHS overload anyway, then
> the LHS override should trigger first, which simplifies the operation of RHS
> overloading.
...sometimes.
Consider:
any(@vals) ~~ all(@othervals)
versus:
all(@vals) ~~ any(@othervals)
Because conjunctions take precedence over disjunctions, in the first
case it's easier to implement if the LHS overloading fires first. But
in the second case, it's easier to implement if the RHS overloading
fires first.
So I guess I ultimately don't really care which order the two cases are
tested, since it will be more convenient approximately half the time and
more awkward the other half. ;-)
Damian
Thread Previous
|
Thread Next