Front page | perl.perl5.porters |
Postings from July 2010
On Thu, 15 Jul 2010, Joshua ben Jore wrote:
> On Thu, Jul 15, 2010 at 1:50 PM, Jan Dubois <jand@activestate.com> wrote:
> > Once you implement magic/overloads that violate the underlying algebraic
> > relationships in your overloaded operators you will end up in a world
> > of pain. E.g. the following expressions should always be true:
> >
> > ($a + $b) == ($b + $a)
> > ($a < $b) == ($b <= $a)
> > "$a" eq $a
> > ($a eq $b) && ($b eq $c) == ($a eq $c)
>
> FWIW, while I'm otherwise in agreement, I wouldn't want to impute
> parameter reordering to operators like + because of their common
> overloading to mean string concatenation.
>
> "X" + "Y" == "Y" + "X"
Well, that was part of my point: *Don't* use "+" for concatenation,
use ".". There is a reason Perl uses different operators for addition
and concatenation; don't try to undo this separation.
> This isn't reasonably true if these strings are some kind of object
> that does concatenation and == is maybe something other than numeric
> equality.
I can see that *maybe* "==" (and "!=") could be used for some kind of
identity comparison, but only if using the object in numeric context
otherwise throws an error. If this doesn't throw an error:
($a + 0) == $a
then "==" really needs to implement numeric equality (and the expression
above needs to be true).
Note that I'm not saying that you can't violate these guidelines. Just
that if you do, then you cannot reasonably expect consistent behavior
from Perl.
Think about the case where you have 2 objects of different types that
both overload the same operator. For binary operators the object on the
left side of the operator determines the overloading method. The
object on the right hand side will probably be coerced to string or
number format during the whole operation. There is no way to predict
what will happen unless both types implement sane overloads.
The best summary is probably the first line of the SYNOPSIS of IO::All:
| use IO::All; # Let the madness begin...
Cheers,
-Jan
Thread Previous
|
Thread Next