Don’t miss part II of the interview with Graham Hamilton, Sun Fellow in the Java Platform Team at Sun Microsystems.
Tiger and Beyond, the Future of the Java Platform
“Code should do what it seems to do – developers shouldn’t need to worry about clever language side effects or about what “=” means this week.”
I think Sun broke this rule in 1.5 when they added autoboxing and static imports. :-/
You misquoted, it should read…
“Code should do what it seems to do – developers shouldn’t need to worry about clever language side effects or about what “=” means this week, except in the cases of when we added autoboxing and static imports.”
Agreed about autoboxing and static imports. But I really would like to see Java get some form of user defined operators. My previous fave language of all time was Algol 68 which while not widely popular did set the pace for 20 years or more of programming languages. Algol 68 provided user defined operators and they really are invaluable. I’m fed up with doing vector algebra in the following form (and vecmath is clumsy even in the OO mould):
a.add (b)
a.sub ©
a.cross (d)
instead of
(a + b - c) /\ d
which is how I wrote it in A68.
Unfortunately C++ has muddied the waters badly and anyone in recent years who has played with user-defined operator has come away with the impression that it is a bad thing. It need not be.
(1) Don’t allow the assignment operator to be overloaded - that really is bad (and was not allowed in A68 ).
(2) Only allow new meanings of operators to be supplied - redefining addition between ints really is bad (and was also not allowed in A68 )
In an OO world I’d be quite happy to go with something really simple such as ‘+’ between object types gets expanded so that
a + b == a.add (b)
and so forth. It is now just syntactic sugar and there is no new semantics. Generics would make this much more workable as well.
Probably the only remaining argument against operators in my book is the 'pure’ness of operators - i.e., operators are expected to be side-effect free (and this is enforced in Fortran 90 which follows the Algol 68 heritage in its approach). I’m not sure what ‘pure’ what mean in an OO world… without going the full functional route.
Of course we would need a new stable of operators to play with as well - A68 provided a general grammar for creating new operators (such as /\ above along with / and many others) but that is probably not a Java way of doing things.
Dave
I’ve always disagreed strongly with operator overloading, but not the ability to define new methods that can be used syntactically like operators. Thusly:
float cos = a dot b;
or
Matrix4f result = a mult b;
Cas 
Operator overloading is a hot carrot. When used correctly it can improve the readability of code, but when used incorrectly it produces mayhem.
My opinion is that for the common Java programmer operator overloading is of limited use, therefore it’s not worth adding the extra complexity to the language. Also, operators are on the same abstraction level as normal method calls, so they don’t present the programmer’s intentions any clearer (which for example generics and foreach does). But I’m sure most mathematicians and physicists miss it.
Cas, your suggestion looks like Smalltalk. We don’t want that.
[quote]Algol 68 provided user defined operators and they really are invaluable.
[/quote]
In the interests of fairness, you don’t mean that.
You mean “…for a strictly limited set of use-cases, one of which happens to be 3D algebra, which happens to be very popular in games development, but otherwise isn’t widely used”.
Personally, (i.e. not @ Dave) I think:
- people who complain that a.dot(b) is bad do have a point but really are just whining :P. I’ve written quite a few software 3D engines and actually, when all is said and done, your code is VERY readable if you use sensible naming conventions, and potentially a lot BETTER than redefining operators.
For instance, the (general [X]) ability to distinguish between:
- a dot b, result in a
- a dot b, result returned
- both at once
- each of the above, with normalisation
- …etc
is IMHO just as “invaluable” as your operator overloading, and yet mutually exclusive. So, overall, IMHO, there is no great loss in not having operator overloading, and it neatly sidesteps an awful lot of pain, both the feared/dreaded and the genuinely experienced.
[X] = also applies to many other aspects of vector algebra. When you have a decent and consistent ;D naming scheme for it, this gets very very handy.
- I’d consider Cas’s compromise, since my main gripe with op-overloading is that reduces your ability to glance at code and know what it does; Cas’s route at least ensures every key operator is EXACTLY what I memorized it as, and I never have to think about them. Except instanceof, which suddenly looks strange (and, incidentally, Eclipse is incapable of auto-completing half the time. Stupid broken parser >:(). Sadly, the anti-op-overloading proponents have a very poor vocab, and tend to say “you can’t glance at code and know what it does”. BS. We all know that’s not true. But…what IS true is that the percentage of code on screen where you have to engage your brain reduces/increases dramatically.
In addition, op-overloading converts arbitrarily long AND DESCRIPTIVE method names to excessively short and NON-DESCRIPTIVE names. c.f. all the arguments over long/short var-names. Ignore the final outcomes, where IDE’s auto-complete made the arugment redundant, and revise some of the pros of long names.
So IMHO op-overloading increases the programmer workload for all maintenance, at the saving of initial prototype workload. So … like a scripting language, really. Funny how C++ programmers tend to try and sneak in scripting-lang features elsewhere whilst declaiming how terrible scripting languages are and incapable of real programming (tongue-in-cheek!).
- Seeing as it’s a (large) niche desire, it would seem sensible that some proprietary extension allow for it - like AspectJ and friends. What really intrigues me is that despite the multitude of such add-ons, there don’t seem to be any major ones for op-overloading (are there any?). Which leads me to seriously question the validity of op-overloading as a “much needed” feature…
blahblahblahh wrote:
No I really do! 3D algebra is a big one granted (and IMHO a very important one) but not the only one. Differential algebra is another. Pattern languages and regular expressions can also make good use of operators without having to parse a string with a grammar that can’t be checked at compile time. It’s hard to remember all the uses of operators because they used to be such a common element in my toolkit.
It’s interesting that you mention the new foreach statement - that adds nothing but syntactic sugar, yet I’m tidying up (and making intelligible again) vast tracts of code that had horrible iterators. Java finally catches up with 30 odd years of good programming language design.
At the end of the day Van Wijngaarden had it right (sorry I don’t have the master’s quote around) - a programming language should seduce you into writing correct code that someone else can understand immediately.
I read math far faster than English. That’s why we don’t use the old Cobol syntax of “add a to b giving c”!
Anyway: rant-off
(a + b - c) /\ d
a is added to be and c is subtracted from it then the result is xored…
Why should be mathematicans tokens better than programmers ones? Mathematicians books are filled just by lots of unreadable symbols where two clear sentences could be better.
firstVector = vm.add(firstVector, secondVector);
vm.add(firstVector, firstVector, secondVector);
is rather clear. //you could even use assambly notation.
Yes if you’d have a predefined unmodificable language syntax for it, you could have a little simplier live. Then again how do you know there is nothing else than addition? There could be a nice funcition that do a little more than addition. Just a few lines more that would be paintfull to write in mathematical notation.
And I coudl instead vm.add(. use qm.add(. Code readibility would be consistent.
(for discusion about consitent “operator overloading” look at the forum.java.sun.com. Search for Lord_of_the_chaos and language improvements block…)
They aren’t a much needed feature really. Structs on the other hand are
Cas
I can see this is a matter of background and taste as much as anything! My background is maths & physics so operators are natural to me.
But I don’t want to start a religious war here - blahblahblahh probably has it right with his suggestion of an AspectJ like extension and see if evolution favours it as it did with generics and Pizza. Ho hum, yet another project to add to my stack…
Now structs I really don’t see the point of
Dave
Personally, I’m against operator overloading because I have recently begun learning stuff like 3d math were people have used overloaded operators and to me it was confusing. Also, I don’t get the C++ ‘lets overload ( and ) and call it functor!!!’ sure I appreciate functors, but it just seems awkward to me.
Dave, you know some cobol, I’m sorry. 
I’d expect that to be able to be written as:
a.add(b).sub©.cross(d);
which I think makes as much sense as operator overloading, and probably more.
[quote]Now structs I really don’t see the point of
[/quote]
Personally, I actually do struggle to see the point of structs!
I think this is probably because of my shortage of non-Java dev experience.
I’m guessing the “cool” thing about structs is that you could write (psuedocode):
MyStruct ms = ...;
out.write(*ms, 0, sizeof(ms));
Is that right? i.e. That’s how structs are used in C/C++?
When people ask for Java to have structs, is this the use case that they’re really asking for?
i.e. the ability to write out an object (without all the serialisation crud) without having to write each element to a ByteBuffer?
Or was the whole dialogue about wanting structs a joke that has now become at my expense? 
yup, thats one of the primary reasons.
[quote]“you can’t glance at code and know what it does”
[/quote]
When this happens to me, I know I’ve done something stupid, or I coded it really fast, so I rewrite it immediately. It also always happens whenever I look at code outside of an IDE, even with plain syntax colorizing. I mean, you can’t know what’s a class, what’s an instance/static method/field, etc., just by glancing your code. Everything feels mixed up (and I’m talking about standard Java code).
That’s why I never code outside of my IDE. My brain can’t function properly without the intuitiveness of having non-local variables colored specially, methods in bold, static stuff in italics, etc.
On topic: I wouldn’t mind some form of operator overloading, but I’d NEVER use it without help from a decent IDE.
NO, that wasn’t what structs was about!! Structs was about memory mapping fields in a Java object to a direct byte buffer. And nothing else. Structs I now realise was such a bad, loaded, name for them. Sigh.
And as for operator overloading: the reason it has so singularly upset everyone is because no-one can agree what silly squiggles mean what. Maths is full of symbols you can’t type, so C++ people have generally overloaded all sorts of symbols in imaginative ways. If we stuck to method names as operators we’d get the best of both worlds: proper operator overloading and readable code.
Cas
[quote]…Structs I now realise was such a bad, loaded, name for them. …
[/quote]
Shouldn’t that be “such a bad, overloaded name…”?
J/K
;D
groan
what is wrong with autoboxing?