Front page | perl.perl5.porters |
Postings from August 2012
On Fri, Aug 24, 2012 at 3:08 AM, Damian Conway <damian@conway.org> wrote:
> Jesse Luehrs argued:
>
>> None of these use cases are for overloaded objects on the lhs of the
>> smart match, which was the subject here.
>
> Sorry, it wasn't obvious to me in reading your previous message that you
> were focused solely on the LHS case. I apologize.
>
> Here are six cases where LHS overloading would matter too:
>
> 1. A lazy string class, which loads text from disk on-demand:
>
> if ($lazystring ~~ qr/pattern/) {...}
>
> # i.e. want LazyString's overloading, not a regex match
> against stringified
> # $lazystring object's address
>
>
> 2. An interval class:
>
> my $reading = Interval->new($raw_data, plus_minus=>$uncertainty);
>
> if ($reading ~~ 0) {...}
>
> # i.e. want Interval's overloading, not a numeric match against
> # $reading object's address
>
>
> 3. A query-result class, which encapsulates the outcome of a
> database lookup:
>
> my $result = $db->find($query);
>
> if ($result ~~ 'camel') {...}
>
> # i.e. want QueryResult's overloading, not string match against
> # $result object's address
>
>
>
> 4. An iterator object:
>
> my $iter = get_iterator_over($data_structure);
>
> until ($iter ~~ undef) {
> ...
> }
>
> # i.e. want Iterator's overloading, not definedness match against
> # $iter object's address
>
>
> 5. A DNA sequence object:
>
> if ($dna_sequence ~~ qr/GATTACA/) {...}
>
> # i.e. want DNASeq's overloading, not regex match against
> # $dna_sequence object's address
>
>
> 6. Prototyping a smarter dualvar with a Chip-like memory of its origins:
>
> my $dv_n = SmartDualVar->new(0)
> my $dv_s = SmartDualVar->new("zero");
>
> say $dv_n;
> say 0+$dv_s;
>
> if ($dv_n ~~ 0) {...} # succeeds
> if ($dv_s ~~ 0) {...} # fails
>
> # i.e. want SmartDualVar's overloading, not numeric matches
> # against the $dv_n and $dv_s object's addresses
None of those require LHS matching to be above CodeRef matching, let
alone above RHS overloaded matching. In fact I'd say in all of them it
makes sense to have CodeRef matching above LHS matching. In my
experience, RHS coderefs mean "I'm explicitly overriding whatever
would happen otherwise".
> In other words, every single time an object is the LHS operand of a
> smartmatch, we need (at least the option) to be able to have that object
> decide how the match should work.
I guess. Conceptually left handed matching and right handed matching
feel like completely different, because left hand is usually about the
$self and right handed is about the $other, to the point where I'd
almost suggest making them separate for purposes of operator
overloading.
Leon
Thread Previous
|
Thread Next