[969] in java-interest
Re: overloading of operators
daemon@ATHENA.MIT.EDU (Walter Smith)
Tue Aug 15 23:41:44 1995
Date: Tue, 15 Aug 1995 17:38:45 -0800
To: java-interest@java.sun.com
From: wrs@newton.apple.com (Walter Smith)
It seems that most of the pro-overloading comments are from people who only
read their own code. Their arguments are valid in that situation.
However, if Java is to be a general-purpose language, it needs to perform
well in more public situations.
> However, programmers can be measured by their code, and
> good programmers should not be afraid of tools which test their skill.
I do not want to have to deal with code that was written by someone who
tested his or her skill and FAILED. And who among us can say they have
never gotten too clever for _themselves_ when given a powerful language
feature?
> I notice no-one is complaining about the hard-wired Op-Ov in the
> String class ...
Uh, for the record, I am. I would much rather have another operator added
to the language than an overloaded operator. Unfortunately, choosing C as
the base language has pretty much taken up all the single-punctuation
operators, but how about >< or something? (Counterexample: choosing Pascal
as the base syntax for NewtonScript allowed me to use & as the string
concatenation operator.)
Simply put, when you look at a piece of code, you need to know what it
does. I also claim you should be able to tell, _without thinking about
it_, which parts you wrote, and which parts are the language itself.
When you're thoroughly immersed in something, sure, it makes sense that +=
should mean Database::Add or whatever. The left side is a Database
object--obviously it's the overloaded +=, right? But this only works
because you have all those header files right there at the front of your
mind.
When I try to find a bug in your code, or when you come back to it after
writing N-body simulations for six months and have forgotten all about
databases, it's a different story. Now you have to be paranoid about all
those operators. Which ones did you overload? On what classes? That +
over there...hmm...
Another issue: If it looks small, it looks cheap. That + sign may be
costing unbounded amounts of space and time, but most people are trained to
think it's a one-cycle integer add. Sure, if you ask them, they may know
what it is, but when they're quickly scanning the code, they pass right
over it.
Of course, all of these things are only a problem if you _overload_
operators. There's nothing here that applies to _new_ operators that you
create.
> Operator overloading is a convention borrowed from centuries of
> mathematicians, and I see nothing wrong with it.
[Speaking as someone who has a math degree and is at least slightly
qualified to throw stones:] If we let mathematicians design the language,
we'll have single-character variable names in ten different fonts. :-) It
is also a convention of mathematicians to invent _new_ operators for
things, to the horror of typesetters everywhere.
So I agree with a few previous folks:
- DON'T allow operator overloading.
- DO allow new operators to be defined, if you must.
Of course, the latter is an interesting parsing problem, but not an unknown
one. ML, at least, does it.
- W
---------------------------------------------------------------------------
Walter Smith Internet: wrs@apple.com
Newton Software AppleLink: WALTER.SMITH
Apple Computer, Inc. PGP key at ftp://ftp.apple.com/pub/wrs/PGP-key.asc
+1 408 974 5892 E1 20 C3 0A DE 27 89 06 0B 35 08 65 0C FB A7 41
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
