On Wed, Aug 12, 2009 at 11:04 PM, Reinier Zwitserloot <reini...@gmail.com>wrote:
> > 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! I said "talk about crying", you know as well as I do that crying is for P/L SQL:ers. > > > On Aug 12, 9:28 pm, Viktor Klang <viktor.kl...@gmail.com> wrote: > > On Wed, Aug 12, 2009 at 8:46 PM, Augusto <augusto.sellh...@gmail.com> > wrote: > > > > > On Aug 12, 1:23 pm, Reinier Zwitserloot <reini...@gmail.com> 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 > > > -- 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 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 -~----------~----~----~----~------~----~------~--~---
