Casper Bang wrote: > That's indeed the idea of abstraction, being able to express intent > with course, context-free building blocks. Java caters to the > philosophy that we should expand though the library, which is > admirable. The problem is that the core language does not really > support this very well. With no operator overloading, we are left with > BigDecimal oddities. With checked exceptions, closures becomes really > hard. Without properties, binding can not be type safe etc. > 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. 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 :-( -- 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 -~----------~----~----~----~------~----~------~--~---
