Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!tut.cis.ohio-state.edu!osu-cis!att!ihlpb!nevin1
From: nevin1@ihlpb.ATT.COM (Liber)
Newsgroups: comp.lang.c++
Subject: Re: Improved switch statement
Message-ID: <9276@ihlpb.ATT.COM>
Date: 27 Dec 88 21:43:13 GMT
References: <6590072@hplsla.HP.COM> <1106@etive.ed.ac.uk> <33528@bbn.COM> <1907@ogccse.ogc.edu> <574@redsox.UUCP> <9245@ihlpb.ATT.COM> <781@auspex.UUCP> <9264@ihlpb.ATT.COM> <581@redsox.UUCP>
Reply-To: nevin1@ihlpb.UUCP (55528-Liber,N.J.)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 47

In article <581@redsox.UUCP> campbell@redsox.UUCP (Larry Campbell) writes:

>It is an EXTREMELY bad engineering practice to use deceptive or misleading
>names in programs.  Well-written programs inform and educate the reader --
>they do not surprise or deceive him.

I agree with you here.  However, it is very hard to take function names
out of its' environment; ie, the context of the program it appears in,
and then say that it is badly named.  My example was to show what is
possible, legal, and in some circumstances, 'good'.

>Remember, operators are just function names.  It is possible, but foolish,
>to define a function called "sqrt" that returns, say, the cube root of its
>argument.  It is also possible, but equally foolish, to define an "=="
>operator that does something radically different than what most people
>expect from an equality operator (like not being commutative, not returning
>a boolean value, etc.)

I suppose you would say that it is also possible, but equally foolish,
to define a "<<" operator which does something radically different
than what most people expect from a bitwise shift operator, like putting
something out to a stream.  Or to define a "*" operator which is not
commutative, as in the case of matrix multiplication.  Or having a "+"
operator which is not associative, which most languages that implement
floating point have; or not commutative, as in the case of string
concatenation.

I agree that "==" should mean "equality"; however, I do not agree that
"==" should (necessarily) mean "equality that is commutative and always
returns a 0 or a 1", especially in cases where this meaning is not
appropriate for the given class.  The language does not and cannot
enforce these properties; it is dangerous to assume them true and
develop new *language* features based upon them.

BTW, all of this is irrelevant to the original discussion.  The point
is that, whether or not we like it, C++ allows you to define an operator
just about any way you want.  The only useful way to used the proposed
change to the switch statement requires that I know exactly how it gets
rewritten as an if-then-else chain, in which case I would rather use the
if-then-else chain, since it is more 'self-documenting'.


Obligatory C++ feature proposal:  I would like a *complete* set of compound
assignment operators.  I propose that ===, !==, ||=, &&=, =< (<= is
already taken), =<=, =>, =>= be added to C++.  Any takers? :-)
-- 
NEVIN ":-)" LIBER  AT&T Bell Laboratories  nevin1@ihlpb.ATT.COM  (312) 979-4751