[1014] in java-interest
Re: overloading of operators
daemon@ATHENA.MIT.EDU (Paul R. Potts)
Wed Aug 16 19:59:53 1995
Date: Wed, 16 Aug 95 16:12 EDT
To: wrs@newton.apple.com (Walter Smith)
From: ppotts@frymulti.com (Paul R. Potts)
Cc: java-interest@java.sun.com
After reading Walter Smith's arguments regarding the cost of op-overloading,
and thinking a little bit harder about the *goals* of Java vs. the goals of C++,
I hereby reverse my position. Java should be left without it. But if it
is without it, strings should not have it either. Supporting the + operator
for strings is a hidden-cost operation (as Walter pointed out) that isn't
necessary, and gives the new programmer (me) the illusion that they can use
other operators, and then wonder why the compiler is complaining.
Using C++ for an extended period of time makes me forget that I like
programming in simple languages (Pascal, NewtonScript, Dylan).
>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'm still struggling to clean up the memory-leak mess I made when I tried
to introduce references and reference-counting everywhere into my last set
of C++ classes, and then crashed face-first into the fact that C++ wouldn't
allow you to change a reference : ) I did seem to get some operator
overloading working OK, but it is admittedly not transparent to someone
reading the code for the first time. I think this is a good point given
that one goal of Java code seems to be to share code as widely as
possible; most of the web sites I've seen so far that have Java executables
on them also have the source. Maybe, with Java, programmers will again be
proud enough of their work to hand out the source.
>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...
A very good example of operator overloading gone crazy can be found in the
TurboVision class library from Borland, which becomes clear after you've
gotten way into it, but is completely opaque otherwise. Even after it
has become clear, the memory-management issues raised by the inserting
of pointers to classes into other classes using overloaded constructors
and + operators are not always simple to resolve, since you can be staring
a serious memory-leak bug right in the face and not recognize 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.
I can't comment on Walter's suggestion to allow new operators to be defined,
since I don't think I've ever used a language that allowed it. (I could be
wrong and just didn't recognize it at the time).
I do very much appreciate Java's overloaded *methods*, and the fact that,
for example, it is very easy to output every built-in type (as in C++ streams).
I'd like to see even more variations on overloaded methods in the class
libraries so that given a number of different available sets of variables,
I can find a method that will do what I want without having to do a lot
of explicit conversions.
-Paul-
=/=/=/=/= Paul R. Potts =/=/=/=/= Software Engineer, Fry Multimedia =/=/=/=/=
"Geeks With Pecs!" ppotts@frymulti.com http://frymulti.com/~ppotts
Geek 3.0: GL/CS d-(---) s+:>- a27 C+++$ US--- P+ L E--- W++ N++ K w--$ O-
M++$ V+ PS++ PE- Y+ PGP t+ 5? X? R tv->-- b+++ DI++ G+ h-- r++ n+ y++**
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
