Incongruous purposes
Latest update:
Date: Thu, 14 May 2020 14:41:57 -0400
From: Doug McIlroy <doug-bJGkzYaaMJvEkZP4S/TgZg@public.gmane.org>
Newsgroups: gmane.org.unix-heritage.general
Subject: Re: v7 K&R C
User-Agent: Heirloom mailx 12.5 7/5/10
Message-ID: <202005141841.04EIfvEZ063529@tahoe.cs.Dartmouth.EDU>
> o operator overloading
>
> I never could figure out why Stroustrup implemented that "feature"; let's
> see, this operator usually means this, except when you use it in that
> situation in which case it means something else. Now, try debugging that.
Does your antipathy extend to C++ IO and its heavily overloaded << and >>?
The essence of object-oriented programming is operator overloading. If you
think integer.add(integer) and matrix.add(matrix) are good, perspicuous,
consistent style, then you have to think that integer+integer and
matrix+matrix are even better. To put it more forcefully: the OO style
is revoltingly asymmetric. If you like it why don't you do everyday
arithmetic that way?
I strongly encouraged Bjarne to support operator overloading, used it
to write beautiful code, and do not regret a bit of it. I will agree,
though, that the coercion rules that come along with operator (and
method) overloading are dauntingly complicated. However, for natural uses
(e.g. mixed-mode arithmetic) the rules work intuitively and well.
Mathematics has prospered on operator overloading, and that's why I
wanted it. My only regret is that Bjarne chose to set the vocabulary of
infix operators in stone. Because there's no way to inroduce new ones,
users with poor taste are tempted to recycle the old ones for incongruous
purposes.
C++ offers more features than C and thus more ways to write obscure code.
But when it happens, blame the writer, not the tool.
Tags: quote, ойті
Authors: ag