> > I first thought that "==" and "eq" were cut from the same cloth as
> > "||" and "or" that is the difference was precedence. Then I learned.
>
>
> Mr. Scott's experience is evidence for a strong argument AGAINST operator
> overloading.
Huh???
I draw exactly the opposite conclusion: If "==" were overloaded to
automatically Do The Right Thing for numbers vs strings as operands,
there would have been no confusion in the first place!
> If we allow object types, and allow object types to overload,
> we lose the clarity we have in a language that doesn't have
> these things.
>
> Maintaining code with perl5 package-modules is difficult enough, but
> at least all the object method calls are explicitly object method
> calls and there aren't any object method calls masquerading as
> well-understood builtins!
So these:
$vec4 = $vec1->add($vec2->unit->cross_product(
$vec3->unit)->dot_product($vec1->unit);
$diff = Math::BigFloat->new((Math::BigFloat->new((
Math::BigFloat->new((Math::BigFloat->new($China{gdp}
->fmul($China{gdp_incr})))->fdiv(Math::BigFloat->
new($China{pop}->fmul($China{pop_incr})))))->fsub(
Math::BigFloat->new(Math::BigFloat->new($USA{gdp}->
fmul($USA{gdp_incr})))->fdiv(Math::BigFloat->new(
$USA{pop}->fmul($USA{pop_incr})))))))->fabs());
are better than these:
$vec4 = $vec1 + ~$vec2 x ~$vec3 . ~$vec1;
$diff = abs(
($China{gdp}*$China{gdp_incr})/($China{pop}*$China{pop_incr})
- ($USA{gdp}*$USA{gdp_incr})/($USA{pop}*$USA{pop_incr})
);
Surely not?
Operator overloading can certainly be abused (hey, I'm building a career
on that! ;-), but it can also significantly *improve* the maintainability
of code, when used correctly.
In other words: it's just like *every* other feature of Perl.
Damian
