Overloading an existing operator such that it changes the performance
in prior situation is evil, evil, evil. Yes, I know it can have some
wins, and I agree they're big ones. But no win is worth having to
debug this (admittedly contrived for the example) situation:
if ( ( $ares = A() ) && ( B() ) ) {
# A and B succeeded, go do something
} elsif ( $ares ) {
# A succeeded but B failed, do B cleanup
} else {
# Do B differently because A failed
}
If the overload means that now A() and B() will now both be processed
no matter what, that block of code is going to go south in a deeply
undetectable way. And finding the bug is going to be bloody hell. This
argues that overloading should be restricted in its scope.
Now consider some poor maintenance coder. He's looking at his main
and a module, trying to figure out why something doesn't work. Both
contain a test like
if ( A() && B() ) . . .
In main it works one way, in the module it works the other. Is it
reasonable to expect that? I submit not.
With humble acknowledgement of my debt to Socrates, I submit that
this dilemma shows that either solution - universal overloading or
localized overloading - leads to extreme difficulties in maintenance.
IMHO, overloading is just syntactic sugar - `it looks cool.' If
we need an &&/|| operator that always tests both sides, lets
make them -- &&& and |||. That's a tiny new thing in perl, while
avoiding deep, deep problems introduced from overloading standard
operators. If someone wants a &&/|| that does something wildly
different, then write a module-specific or general function for
it
Overloading existing operators is evil, evil, evil. Operators are
not class-specific functions. They're core language constructs
and the programmer should be able rely on them to remain fixed
in function.
And in conclusion I'm opposed to this. What I tell you three**3
times is true**3. :-)
