[927] in java-interest
operator overloading
daemon@ATHENA.MIT.EDU (Glen C. Perkins)
Tue Aug 15 17:20:52 1995
Date: Tue, 15 Aug 95 10:29 WET DST
To: java-interest@java.sun.com
From: Glen.Perkins@NativeGuide.com (Glen C. Perkins)
I also vote "NO" on operator overloading, but I think there might be a
compromise that allows what I mean when I say NO to co-exist with what the
proponents (mostly) mean when they say YES.
When I say "no overloading," I mean that when I see something in somebody's
code such as +, -, min(), etc., I want it to always MEAN the same thing,
or I want to come as close to this ideal as possible. I want to be able to
make lots of SAFE assumptions. When I see something like foo(), I can also
immediately assume that this is something defined by THIS program that I
need to go look up because it could do anything. When I see a "+", I know I
understand it already, and that there is no danger that it isn't what is
seems to be.
One of the great things about Java is how hard it works to make assumptions
safe for us. An int is 32 bits & signed in every program on EVERY machine,
so when I see it in somebody's Java code, I can assume things about it that
would be dangerous to assume in C. When I work with a char, it doesn't
matter whether I'm working with a roman letter or a Japanese kanji. Because
Java uses Unicode (bless you, Sun!!) the third char in a string is always
the third char in the string, not the third byte in a memory range if this
chunk is ASCII, but the 5th AND 6th byte in the range if kanji (ASSUMING
that it was preceeded by two other kanji because if not, that "assumption"
will become an "intermittant bug" unless you count bytes, one for ascii,
two for kanji, perhaps with escapes between them...! AAArrgh! LOVE YOU
Java!)
Everyone makes assumptions, usually without even being consciously aware
that they did so. Java just makes it safe(r) to do so. The more you can
safely assume, the faster you can go. C++'s attitude is "you can't take
anything for granted. If you don't understand EVERYTHING about this
program, you can't assume you understand ANYTHING!" Nuts to that!
Being able to throw a new programmer at old code and get a fast, bug-free
upgrade out of him in the shortest possible time is money in the bank for
me. The faster and more accurately he can grok the code, the more money I
make and the more secure his salary. If there is no such thing as operator
overloading, it makes it that much better for both of us.
The major argument of those who want operator overloading is that they can
actually make their code EASIER to read (and perhaps write) if they use it
correctly. The strongest example I've seen is being able to do complex
arithmetic with a line like:
c = (a + b)/b;
This, they say is cleaner and easier to understand than forcing them to write:
c = complexDiv( complexAdd(a,b) , b);
I agree, but as has been said by so many of you, this example is not
sufficient to justify ruining the whole language by making all operator
assumptions potentially unsafe in order to accomodate it. They say, "any
tool is capable of being used well or badly" but if the tool exists at all,
it will slow down everyone's parsing of ALL code and therefore cost me
money. No. It's not worth it.
I could live with things as they are (having to use the second form above),
but it appears that many people feel otherwise, and it would be nice to
"convert" them to Java, too.
When people speak of operator overloading, they never bring up examples of
unary or trinary operators. They seem only to want overloading so they can
stick a binary operator between its two arguments instead of in front of
them using function (method) notation.
Why not allow the creation of binary "operator" methods with the operator
syntax, but not allow the operators themselves to be reused? Perhaps any
2-argument method could be used with either normal or operator syntax. The
above example could then be written as:
c = (a complexAdd b) complexDiv b;
This would tell you immediately that the "operators" were user-defined when
you tried to read a line like this in someone else's code so you would be
less likely to make unconscious assumptions about them.
As I said, I don't need this new syntax myself (though it might be nice to
have at times) and I want NO OPERATOR OVERLOADING. I want to be able to
make as many assumptions as possible as safely as possible.
I would be interested to know if this syntax would satisfy those who desire
operator overloading, or whether they would only consider using Java if we
allow anything to mean anything and make all assumptions potentially
unsafe.
__Glen__
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
