Casper Bang wrote:
>> 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.
>
Once you throw scaling and rounding policies and the like in then
operators fail anyway. If you end up having to use more than just +, -,
*, and / for their obvious meanings then you're better off using method
names.
Your example does make clear a simpler need, however -- there should be
simple BigDecimal literals.
>> 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.
>
I wasn't meaning to argue for or against closures or the whole
controversy there. Rather to point out that just one piece of one
proposal, BGGA's exception transparency, does wonders to address checked
exception issues -- and does so in contexts beyond just closures.
While I'm for closures overall (but want to see them done "right" the
first time), I'm /hugely /for exception transparency. This is not a
small language change from an implementation or specification
standpoint, but it adds very little conceptual/learning burden and
rounds out a lot of Java's sharp corners. That's a win in my book.
It's a big change, but it really simplifies generics and exception
handling -- and is much more important than reification in my book as well.
--
Jess Holle
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
