Overloading and Smooth Operators
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.'"
Sure, there are lots of things you can do with operator overloading, but there are good reasons to avoid them. Ultimately, it comes down to some basic questions:
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.
Contrary to the article that states that a++ and ++a can be aliased to one call a.next() this is not how it should be done: ...)
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
Search your logs like the web: splunk!
It's extremely useful for solving, i.e. the following two problems.
tasks(723) drafts(105) languages(484) examples(29106)
Used poorly, it results in crap. But does that mean that we should block off entire development tool from programmers?
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
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
You're entirely wrong. Groovy is another language that targets the JVM. Groovy is either compiled to Java bytecode (and from there, JIT compiled to machine code by the JVM), or it's compiled at runtime in a JIT fashion. There is no interpreter written in Java that runs Groovy code. Groovy is just another language that targets the JVM.
The benefit from all this is that in Groovy, you can interface to Java classes with literally no overhead. It's a brilliant idea for a new language because all the libraries are already there! This skips past one of the biggest stumbling blocks for new lanaguages.
All in all, Groovy's a pretty interesting language that's worth looking into, but apparently you can't be bothered to do a Google search.
I love the smell of hypocrisy in the morning. It smells like... coffee.
Seriously, operator overloading is a powerful technique that, done right, allows you to write clear, expressive, maintainable code. Done wrong it allows you to write foul spaghetti, but any language allows you to write foul spaghetti --- Flon's axiom: There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs.
Not allowing operator overloading (except when the language authors break their own rules) has no effect other than to reduce the options available to the programmer. It means that while you can't use them in cases where operator overloading is not useful, it also means that you can't use them in cases where operator overloading is useful and would produce better code. It means you can't, for example, create an imaginary number class that works the same way as int or long. This is not the mark of a good, extensible, expressive language.