[1021] in java-interest
Re: java-interest-digest V1 #121
daemon@ATHENA.MIT.EDU (Walter Smith)
Wed Aug 16 22:39:32 1995
Date: Wed, 16 Aug 1995 16:24:44 -0800
To: java-interest@java.sun.com
From: wrs@newton.apple.com (Walter Smith)
Cc: tomw@intelligraphics.com
I think this is getting rather off-topic, but I can't shut up quite yet...
>Detractors argue that the [un-overloaded version] is
>more readable because you _know_ what SomeFunc() and AnotherFunc()
>do - you don't have to guess at their meaning.
You have misrepresented my position (and are thus responding to your own
strawman argument).
I argue that the un-overloaded version wins because you _know_ SomeFunc()
and AnotherFunc() are functions and not built-in language operations. You
also know that you _don't know_ what they do or how much they cost unless
you've looked at their implementations. Furthermore, you know this as soon
as you see the expression--in the "syntax phase"--and not after you've
figured out all the types in the expression.
In other words, my position is the _opposite_ of what you said. The point
is, you _don't know_ what any functions do without a long study, and you
should never be allowed to forget it!
>Operator overloading
>is easier to abuse, true - but because operators have (typically)
>well-defined meanings it should also be easier to adhere to those
>meanings.
On the contrary. Because operators have well-defined meanings, it is
_more_ confusing when they are overloaded. The whole point is that you
should only be able to redefine things that _don't_ have "well-defined
meanings", because then you're on the alert to ask what the meanings
actually are.
The only "well-defined meaning" of + in C++ is that it adds two numbers of
built-in types. That's it. (Even _that_ isn't very well defined, judging
from the number of times I have to look at the type-conversion table.)
- 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
