Why can't we have operator overload in Java?It sickens me to no end to see other languages using that for their game programming such as adding vectors and substracting them with simple -/+ instead of the crappy .add/.sub that we're accustomed to in Java.Everytime I talk to one of those die-hard c++ programmers about what I can do with Java gaming wise they burst laughing at how we can't use what they think of as mandaotry in game syntax and coding.Geesh Sun must have one of them ultra-good reasons to not allow us to play around with em operators.. /end rant

The widespread abuses of operator overloading in C++ have made this a religious issue. Those who oppose operator overloading do so with a fervour unmatched by any ayatollah! Most of this could be defused if we could find a way to restrict such overloading to arithmetic types. It doesn't help that '+' has already been overloaded for String values.The best I can suggest is that operator overloading be restricted to argument types which are either primitive or immutable classes. This would remove some of the more flagrant abuses.

I don't really care for PrinceC's model, however operators are nice. Besides it wouldn't be that hard to abuse them and only complete idiots would use * as dot or crossproduct. Besides overloading new and delete would be obsolete in java and thus this would remove 90% of the abuses.

Only fools and newbies used operator overloading in C++ w/o his back to the wall and a knife at his throat! You'll NEVER find the bugs and the code is harder to read! The rules used to find out which operator actually has to be used have been VERY complex and impossible to have in mind in daily work!

For vector 'multiplication' it would be far better to be able to define new operators (for dot and cross products) rather than overload existing operators. However as the obvious candidates don't appear on most people keyboards working with these would be awkward.There is nothing stopping someone from writing an IDE which automatically renders some methods in infix form with an appropriate symbol (define the symbol to be used in the JavaDoc comment for the method). If you include the precedence information you could also avoid adding unnecessary parentheses. The smart IDE might then allow you to type '*' to multiply two vectors and then offer you a choice of the two alternatives.

So what is so wrong with being able to write methods in an alternative syntax? What's wrong with a dot b instead of a.dot(b)? Or lengthof a instead of a.lengthOf()? It'd make the language beautiful to the human reader. You could design your APIs so that they could be read.

<Smalltalk rant>Unfortunately, all three implementations listed have heavy drawbacks and don't feel like Smalltalk at all (at least IMHO). And there's not as freely available as I'd wish.

The last time I checked, SmalltalkJVM requires VisualAge Smalltalk. You use that fine Smalltalk development environment and once ready, you can transform your code. While debugging in Smalltalk is usually a pleasure, you cannot debug cross-language. They want my name for a windows-only download, so I refrain.

Talk2 feels more like Smalltalk but the demo doesn't really work and the website doesn't provide any deeper information and again, I have to fill some some form to download, so I refrain.

Bistro is freely available but a bastard of Java and Smalltalk. To interface Java, a lot of annotations were introduced, it feels somehow alien to an old Smalltalker like me.

And all projects seem to have stoped development in 2002 or earlier (Talk2 talks about upgrading to Java 1.2 sometime?!)

While you can certainly create a Smalltalk-like language that compiles down to a JVM, it is really difficult to create efficient code. Smalltalk's more flexible features can't be mapped onto the JVM directly. Rhino and Jython need to solve similar problems.

Two of the main performance blockers are, that you'd have to root each method call through some invoker method (Groovy does this and on a modern VM, the performance penalty doesn't seem that high any more, we're talking about 5-10x slower method dispatch) and even a single "+" on two numbers would have to check for overflows and must continue to work with BigIntegers seamlessly. You probably wouldn't be able to reimplement Smalltalk-style exceptions at all (Java's try-blocks can't be restarted) and metaprogramming stuff like #allInstances or #become: is probably also out of reach.

Having said that, a decent Smalltalk that compiled to bytecode could be SharpSmalltalk written by John Brant and Don Robertson (I think). These are the two guy who invented the Smalltalk RefactoringBrowser, made the idea of refactoring popular which eventually inspired Fowler to write books about this topic and gave us Refactorings in IDEs like Eclipse or IDEA. SharpSmalltalk is written for .NET but that platform has the same limitations as the JVM so it should be possible to use their technology to create something similar for the JVM.

However, if all what you want is just a fancy "object message" syntax, check out Objective-C which was Brad Cox answer to Smalltalk, using C to add object oriented programming. It's an interesting language and you might wonder why there's no Objective-Java for advanced OO-Programming in Java

And as already mentioned, the Groovy languages tries to combine the best ideas of Java (assuming there are any), Python, Ruby (and therefore Smalltalk) and Lisp to create a decent scripting language especially for the JVM. Interesting goal, but they're not yet there, the current version has still a lot of rough edges.

Last but not least, I'd like to have operator overloading although I don't want operators? Strange? Well, operators are a legancy of primitives datatypes and I'd wish both would have never been part of the language. Something like "a + b" is just syntactic sugar for "+(a, b)" and that way, yes, I'd like to have this kind of binary functions or methods in a language. I'd also like [] and []= as method, to ease indexed access to collections. And I'd never have used + for strings, because that creates unexpected results if you use "a+b="+3+4.

Whatever, that's all just a dream, I don't think that Java will change and it's not the language that I like but the development environment plus the libraries. Hopefully, languages like Groovy or Scala (another very interesting JVM-based functional language) will evolve and will eventually get tool support like Java itself.</rant>

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org