> A side question: even if Java permitted operator > overloading, I have read > comments to the effect that the technique is not to be > preferred. Never having > done much with it in a language that permits it, I don't have > the experience to > know why. As someone who thinks mathematically (at least at > times), operator > overloading seems like the most natural thing to do to > preserve the semantics > I'm accustomed to among number systems that contain one > another (a seemingly > very natural inheritance hierarchy). Can anyone out there > explain why operator > overloading might be considered bad?
changing the implementation of a method via object extension is one of the benefits of a decent OO language. It is well understood and the semantics/contract/side effect rules of a method can be well explained. If you call a method you expect things to happen that you have no control over unless you read the code/docs. In most cases this is fine. .equals() is a meaningful name, If however I am using a class and require a particular equals behaviour with it I should check that the class does what I want it to do (or write my own etc. etc.) When I write == I mean object identity. period. I have no need to check the implementation since the Java spec defines this behaviour. like wise += -= et al for all the primitives. When coding the ground can always shift under your feet. what operator overloading gives you is a whole new section of ground which might drop out from underneath you. this is not a good thing. I actually dislike suns use of + and += with Strings. It confuses no end of people when I tell them "foo" == "f" + "o" + "o" is by no means guaranteed to be true. This is not even true operator overloading, the == is still testing identity and + is being precompiled (albeit by the compiler ;¬) to StringBuffer.append() rather than a genuine virtual method invocation. Truly gifted coders can certainly find a use for virtual operators in achieving 'pretty'* solutions. When 'avaerage' coders come along they don't understand the intricacies involved and bugger the code up beyond belief. Remember that not all coders are as clever as you might want them to be**. code maintenance is, for most businesses***, far more significant in resource cost that the original coding. *Relying* on 'clever'**** features like operator overloading, static method overshadowing, Background canonicalization of Strings, non type safe casting are a real bad idea IMO. Sun chose not to allow the overloading of C++, nor the cast shenanigans of C. they did include some real doozies, like trying to make believe Strings are primitives to the coding process yet making them woefully underperformant for the common primitive alike operations. rant over (honest). I have only met two other developer at my workplace that understood about String == comparisons without me telling them. of them neither understood how compiler optimizations and String canoicalization covered up the problem. Matt * you get what I mean - clean/terse/seemingly effortless ** I certainly wish I was *** those people that pay most of us probably **** anything happening behind the back of a large number of the coders on your project ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
