Exactly. If java had pure operators (where the operator's meaning is independent of the expressions on either side), then adding operator overloading is a mess, but java's operator set is a hopeless mess. Utterly hopeless. It makes no sense at all, and therefore the argument that operator overloading is going to make things confusing makes no sense either; the concept of operator overloading (especially if you add sensible caveats, such as requiring strict type limits (both sides should be the same type, and the operation must also return that type) would be *far easier* to grok than the current meanings of operator overloading.
In case people take exception to my hypothesis that java's operators are a screwed up grab bag of insanity, let me count the ways... (A) The / can mean EITHER integer division OR arithmetic division. The types of the LHS and RHS decide. This is stupid. It's caused a lot of pain because it's stupid. (B) The & operator is strictly binary and, and && is strictly logical and. Exactly why is this different from the behaviour for the slash, where two related but definitely not the same meanings have been overloaded into one operator? While integral and arithmetic division is screwed up all the time, I can't think of many ways in which you could confuse logical and bitwise and! Think about it: Java has no concept of truthy and falsy, and bitwise and cannot ever produce booleans, and the concept of bitwise and/or/xor on 2 boolean values, if it were allowed, would clearly be equal to the logical operators. It's virtually impossible to write something that doesn't do what you think it does, even if you don't know if the compiler has 2 different meanings (logical vs. bitwise). (C) All operators in java are already overloaded; - can for example mean unary minus, binary minus on ints, binary minus on longs, binary minus on floats, and binary minus on doubles (but not binary minus on shorts, bytes, or chars!). However, + is particularly egregious; it can mean all those things AND it can mean string concatenation. String concatenation isn't even commutative (commutative is: a + b has the same meaning as b + a, which for string concat clearly isn't true, but it is true for numeric addition). (D) All binary operators in java are type dependent (e.g. + is long addition if it involves a long but not a string), but it is NOT dependent on type positions. In other words, in "EXPR1 OPERATOR EXPR2", the meaning of operator is the same as in "EXPR2 OPERATOR EXPR1". In other words, 'new Object() + ""' is string concatenation, because '"" + new Object()' is string concatenation. So far so good (this is actually useful, and a common thorny issue with operator overloading in other languages, where this almost invariably does not hold, and a particular side decides the meaning. E.g. in scala, it's the LHS, unless the operator ends in a colon, in which case it's the RHS). However, this property *IS NOT ASSOCIATIVE*, which is just screwed up. Consider: new Object() + "" is string concatenation, but this: new Object() + new Object() + "" isn't. It's a compiler error, because while binary operator meaning is positionally independent, chains of operations are resolved as binary applications from left to right. This doesn't make sense in combination with positional independence. (E) byte, short, and char are special, in that they don't support any operators. Instead, java will automatically widen them up to ints (which does have operators). This creates screwed up situations: byte a = 10; byte b = 20; callMethod(a ^ b); will call the callMethod that takes an int, even if there's a callMethod that takes a byte. This is utter magic to any java programmer. Similarly, this: byte a = 10; byte b = 20; short c = a + b; will generate a 'possible loss of precision' error, eventhough this is clearly bogus; the result of adding two bytes fits, by definition in a short. On the other hand, this: int a = 10; int b = 10; int c = a + b; will NOT give you any warning, but in that case, you really *COULD* have a possible loss of precision. The entire warning is a lie. (F) The biggest bunch of operator overloading haters, project coin, jumped headfirst, with complete abandon, into extending the meaning of [] for list and map access, both reading and setting. So far no one has mentioned that this is operator overloading, and I'm too in love with schadenfreude to bring it up in this early stage. My current plans for lombok in regards to operator overloading are fairly simple. Either (A) it'll be for a hardcoded list of types only (e.g. arithmetic and bitwise operations for BigInteger and BigDecimal, and map/list indexed read access for java.util.List and Map, as well as the google collections API and javolution), or (B) that plus interfaces that you can override, but with the caveat that all types are strictly congruent. E.g: the + operation can only be defined as T + T = T - the two types on either side of the plus sign need to be the same, and you must output your own type as well. This removes a lot of the confusion and conveniently adds associative positional independence, as long as you don't try to mix things with java's own internal set of screwyness. Are you really going to go to a corner and cry about that? Wuss! On Aug 12, 9:28 pm, Viktor Klang <[email protected]> wrote: > On Wed, Aug 12, 2009 at 8:46 PM, Augusto <[email protected]> wrote: > > > On Aug 12, 1:23 pm, Reinier Zwitserloot <[email protected]> wrote: > > > > Incidentally, projectlombok.org's goals are pretty much that: A > > > java.next for the rest of us. Closures, more literals, probably > > > extension methods and operator overloading, properties, lots of > > > boilerplate elimination, et voila. > > > Operator overloading? > > > Let me go to a corner and cry ... > > Use BigDecimal for complex arithmetics, then we can talk about crying. > > > > -- > Viktor Klang > > Rogue Scala-head > > Blog: klangism.blogspot.com > Twttr: viktorklang --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
