Overloading and Smooth Operators 75
An anonymous reader writes "IBM DeveloperWorks has an interesting article on operator ad hoc polymorphism (operator overloading for the uninitiated). With the increase in Java popularity and their banning of operator overloading (among other things) the author decides to show some of the great benefits that operator overloading can bring, as long as it is served with a 'healthy dose of caution.'"
Useful? Doubtful. (Score:5, Insightful)
Will the use of overloading operators...
*) reduce developement time?
*) reduce the number of bugs?
*) improve maintainability?
In most cases, the answer is at best murky. Sure, if you're doing mathematical programming, adding complex numbers, rational numbers (tracking numerators and denominators instead of using floats), or something like that, then it's intiutively a good thing. But in most cases, it's not intuitive. When someone else comes to the project and tries to figure out what's going on, it's like having a bunch of extra macros for them to look up. Function calls make it much more obvious what's going on.
A++ and ++A are NOT the same (Score:4, Insightful)
a++ needs to return the value of a BEFORE it is incremented
++a needs to return the value of a AFTER it is incremented
Sorry for the rant, I've just spent too long working with programmers that didn't know the difference
(Not at my current job mind you
comp.java.lang.programmer 2001 (Score:2, Insightful)
-= cobnet -= wrote:
>
> Now I wonder why Java doesn't allow overriding of operator, because I think
> it makes things a lot easier...
>
> For example... presume you have written a class Point() and that you test
> this class:
> Point p1 = new Point (2,3);
> Point p2 = new Point (46,4);
> Point p3 = new Point (5,8);
> Point p4 = new Point (5,5);
>
> Point p = p1 + p2 + p3 +p4;
>
> Point p = p1.add((p2.add(p3)).add(p4);
>
> Point [] pArray = { p2, p3, p4};
> Point p = p1.add(pArray);
>
It isn't. That seems to be a classic example of abusing operator
overloading. Adding two points together makes absolutely no sense. If
the intent is to create a collection of points, then a Collection should
be used, along with the associated add() methods.
>
> So what made java didn't allow this overriding of operators??
>
A plethora of code similar to your example.
Jim S.
Re:comp.java.lang.programmer 2001 (Score:3, Insightful)
It's extremely useful for solving, i.e. the following two problems.
Re:comp.java.lang.programmer 2001 (Score:1, Insightful)
No, it doesn't. And you'll note that this has nothing to do with operator overloading. Without it, he's still doing p2.add(p3), which is equally meaningless but more verbose.
OTOH, if you have to do, say, fixed point math in J2ME, you end up with code that looks like the bastard child of Lisp and Perl.
There are many wrong places for operator overloading, but it's indispensible for the right places.
Like any tool (Score:4, Insightful)
A properly designed and applied overloaded operator can be a great tool for development.
A poorly designed or inappropriatly applied overloaded operator can create a mess of code and a maintenance nightmare.
Now, replace "overloaded operator" with a blank and fill it in with what ever you like. "data layer", "abstract class", "architexture", etc... But if the powers that be decide that programmers need to be protected from data access, inheritance, and design fundamentals, what the hell are we left with?
-Rick
Blech (Score:2, Insightful)
Yeah, that's a lot more readable.
This is precisely why operator overloading is both unneeded and unwelcome. Like an earlier post said, the benefit doesn't even come close to outweighing the price. "<=>" is a perfect, classical example of how programmers get positively drunk with freedom and treat operator overloading like a shiny new toy. Code full of that instead of "compareTo" is an instant eyesore. I'd rather spend my time developing, not deciphering.
Re:Like any tool (Score:3, Insightful)
If you want an OO language that doesn't try to hedge the coder in with rules for his own good, you aren't programming in Java. You're using C++. If you don't care for inheretance and templates, you may even go staight C. Other than that, most languages these days place safety nets everywhere to annoy you.
Re:Like any tool (Score:3, Insightful)
Its one thing to protect an environment from a stupid coder. Its another to protect a stupid coder from themselves.
-Rick
Re:As long as we're limited to few characters... (Score:2, Insightful)
As usual, there already is a language that allows this, and (as usual) it's called Lisp.
First, in Lisp, + is not a special case in the syntax: it's the name of a function, like anything else. If you want to define a function called *#@!*, there's nothing stopping you. (You can name them pretty much anything, IIRC, but if it has something crazy like whitespace in the function name, you'd obviously have to escape/quote it.)
A lot of people don't like writing some things in prefix notation, so: Second, Lisp (at least Common Lisp) has "reader macros", which let you define your own syntax for the reader. This is possible due to a few (related) reasons: Lisp doesn't really have a syntax -- you're basically writing the ASTs directly -- and all the language is available all the time -- so you can write code to write code at read-time. You can write a reader macro to parse arithmetic in infix notation (like C), for example, and then embed that in your Lisp program.
If you're doing a lot of network transfers and think a special syntax for that would be handy, you can write a function to rewrite your own syntax into Lisp (at read-time, before it gets to the compiler, so it's still compiled).
This is exhibit #473 in "Why isn't Lisp dead yet? Isn't it older than dirt?".