[954] in java-interest
Re: overloading of operators (a new proposal)
daemon@ATHENA.MIT.EDU (Scott Hudson)
Tue Aug 15 21:44:16 1995
From: hudson@cc.gatech.edu (Scott Hudson)
To: java-interest@java.sun.com
Date: Tue, 15 Aug 1995 11:44:43 -0400 (EDT)
I vote that we DON'T VOTE. Language design has way too many subtleties
to do by consensus. Let's argue merits, then trust those with the
original vision to make the right decision.
That said, I'm of two minds about operator overloading. However, I
think I might have a proposal of something new that can make both minds
happy.
Operator overloading can lead to some egregious code which is nearly
impossible to understand. You think you are adding things but you are
really calling the recursive discombobulator. In particular, you have
to know about all the definitions up the superclass chain and can no
longer really understand expressions from local context alone. Note
that is isn't new, methods are always this way, but it significantly
expands the problem.
On the other hand I've found that judicious use of overloading can lead
to important advantages when you are trying to write tools and packages
of reusable code. It allows you to create user defined classes that
are just as easy to use as the built in classes. For example in C++, being
able to say things like "tab["key"] = 5;" instead of "tab.find("key").set(5);"
is really nice. Even better is: "set1 + set2 > set3" instead of
"proper_superset(set1.union(set2), set3);)".
I have an idea for how to deal with this conflict between supporting user
defined classes with the same notational convenience as builtin types,
and the problem of "hidden" operations.
I did this in a small experimental programming language I built a few years
back. The inspiration for it is a notational device you sometimes see in
math or CS texts when they need to talk about hypothetical operators. In that
case sometimes you will see an operator like + with a circle around it. My
proposal is to introduce a series of "circle operators" that are reminiscent of
the builtin operators (look similar and have the same precedence and
associativity), but which are clearly distinguished as "user defined".
They would be used exactly like the builtin operators (hence imply something
about what they do), but would always represent a method call (and it would
always be obvious that they did).
Lexically the operators would be designed with this "circle operator" notion
in mind so they would look like: (+). This is a bit harder to read than the
conventional operators (you can see that most clearly in "(<)" ), but overall
I would claim substantial a win. Assuming that you do not allow any white
space in the middle of the operator (just as you can say "< =") then it turns
out that these are not any harder to deal with lexically than ">", ">>", ">>>",
">>=", and ">>>=".
In addition to the "circle" operators it might also be possible to think
about square [+] and diamond <+> alternatives. In my earlier language I
allowed all of these, but I'm not sure whether I would advocate that here
or not. We would also need to introduce something like the C++ "operator+"
notation for declaring methods. We probably also would want to invent symbols
for an "array-subscript-like" operator (I would suggest "[: <expr> :]") and
perhaps an "assignment-like" operator (I would suggest ":=" and/or "::=").
The upside in all this is that you get both first class user defined operators
and an obvious cue that it is a method call. The downside is probably that
they can be visually a bit hard to parse. If you don't leave white space
around them, then they can be pretty dense in some places. Further ">" and
"<" look bad in all three varieties. You could consider ".<." and ".>."
which are better, but look too much like Fortran :-). Also mixtures
such as "a + b (+) c" may be a bit puzzling WRT to associativity.
Comments?
As changes to the language go, I think this is actually a relatively easy
one -- definitely easier than adding conventional overloaded operators.
Scott
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
