structure and array and string comparisons

Larry Wall lwall at sdcrdcf.UUCP
Tue Mar 27 10:20:13 AEST 1984


In article <2831 at brl-vgr.ARPA> gwyn at brl-vgr.ARPA (Doug Gwyn ) writes:
>...
>I have the same objection to overloading of operators (as in Ada).
>Just because one can use the same symbol (e.g. "+") to combine two
>objects in each of several different classes by no means implies
>that it is the "same" operation in the different classes, or even a
>unique extension.  (Example:  a Boolean "+" could be a "union"; it
>could also be a "Boolean sum".  Which is "correct"?)

Just what kind of an idealistic totalitarian are you?  By this kind of
argument we can rid the world of freedom forever.  Just because a freedom
can be abused doesn't mean we should do away with it.

GIVE ME OVERLOADING, OR GIVE ME DEATH!

Seriously, there are some very good arguments in favor of overloading.

1)  Almost all languages do it surreptitiously already (e.g. what is the
    type of "+" in C?).

2)  The human mind thrives in the presence of overloading and other
    context-dependent activity.  Consult any dictionary for examples.

3)  It helps keep the namespace uncluttered.  No need to make up silly names
    just because you want to do the same (or similar) thing to a different
    type of object.  "Martha, I want to can-open this can."

4)  It facilitates "generic" abstractions.

What a Boolean "+" might mean depends on where I get the definition from,
now doesn't it?  Anyone who uses an operation with semantics they don't know
is asking for it anyway, regardless of whether the semantics come from
a "package" or are built into the language.  If this is indeed the case,
why not release language designers from having to predict ahead of time
all the (reasonable) uses that someone might want to put an operator to,
and give some modicum of freedom to package designers instead.  I assure
you, if the package designers misuse the freedom, people will tend not to
use those packages.

Thank goodness Ada isn't "perfect".  Just a little more perfectible.

Larry Wall
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!lwall
(I'm glad my organization doesn't make me put a stupid disclaimer down
here, which no one ever reads anyway, for reasons obvious to all but a few
bosses...  After all, when's the last time you saw an ORGANIZATION have an
opinion on the net?)



More information about the Comp.lang.c mailing list