Front page | perl.perl5.porters |
Postings from August 2012
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
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.
> (Note that equality operators (.=, etc) already don't check
> overloading on their lhs, so this behavior isn't unprecedented.)
Those are actually assignment operators, which are a very different
beast when it comes to overloading. Overloaded (in)equality operators
certainly do check overloading on both sides.
Damian
Thread Previous
|
Thread Next