> 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 -~----------~----~----~----~------~----~------~--~---