> I'm still not convinced operator overloading is a good thing.
>
> If it can be introduced specifically for BigDecimal in a clean way, so
> that all the operators have a clear meaning and there's little need to
> use the corresponding methods, fine. BigDecimal has 2 add methods, 6
> divide methods, 2 multiply methods, 2 subtract methods, etc, so it is
> not immediately clear that this is possible. That said, I don't use
> BigDecimal, so I can't say from experience. I definitely see more harm
> than good in user-defined operator overloading, though.
Actually it does not have add methods, it has plus methods (it's
immutable). I did not mean to say it should be retrofitted now, I
doubt it's doable in a backwards compatible way, it was just to point
out flaws in Java's "we only extend through libraries" policy. I think
"more harm than good" is a straw man argument but it's been discussed
before and I respect the complexity argument. I'll just make my case
by showing what it takes presently to convert Fahrenheit into celcius:
BigDecimal celcius = ((new BigDecimal("84.7").subtract(new BigDecimal
("32"))).divide(new BigDecimal("9"))).multiply(new BigDecimal("5"));
...and that's without dealing with scales and rounding policies which
usually also end up in the mix.
> As for checked exceptions, BGGA's exception transparency resolves this
> issue. Personally I find BGGA's exception transparency by itself more
> compelling than closures. I'm not saying closures are bad -- just that
> exception transparency is /huge/, with or without closures. Closures
> give nice shorthand, but exception transparency gives increased
> reusability of generic algorithms -- which is far more compelling to me.
> Unfortunately according to Neil Gafter exception transparency is the
> biggest, hardest language change involved in BGGA :-(
Oh yeah, I left out the whole closure controversy previously. :) This
is perhaps the single best example of when we should let experts/
architects do their job and drop the committee/community circus. I
guess by now no one really cares about it, JDK 8 is going to be some
3-4 years ahead in time and by then competitive languages will have
crossed several new boundaries to productivity.
/Casper
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
