Re: Equality operator overloading in ADA 83

[bobduff@world.std.com (Robert A Duff)]

In article <dewar.862718892@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>But in general we follow the rule in Ada of not using the others clause
>precisely because it disables an important check.

I follow a rule more like this: Use "others" only if you want that
alternative to cover all possibilities not mentioned, INCLUDING THOSE
POSSIBILITIES THAT HAVEN'T BEEN INVENTED YET.  E.g. for an enumeration
type, others should conceptually include all the enumeration literals
that somebody might add to the program in some future version.

Yes, this implies that "others" is *usually* not a good idea.  But it
sometimes is a good idea.  For example, a lexical analyzer for Ada might
have a case_statement on characters to do something in particular for
the cases mentioned in the RM as legal tokens, and have a "when others
=> Error;" alternative.  There's really no particular value in listing
all the error-characters explicitly.

(I use the same rule for "others" in an array aggregate.  For record
aggregates, I can't remember ever using "others" -- it's not clear to me
why it's even allowed.)

>... A case statement that
>requires an others is entirely equivalent to a set of elsif's, so why
>have an alternative syntax.

I don't think they're equivalent.  With a case statement (with others)
you still know that the alternatives are mutually exclusive, and that
their evaluation has no dependence on the current state of global
variables.  You know that all the alternatives are testing against a
single value, and you know that expression is evaluated exactly once
(e.g. consider translating "case F(X) is ..." into elsif's).  You know
that the order of the alternatives doesn't matter.  You know these
things as soon as you see "case" -- with elsif's, you have to examine
each condition carefully to gather such information.  Using "others"
does not damage all of these good things, and knowing these things
easily is helpful in reading a program.  If I were extending the
case_statement, I would try to retain these properties.

- Bob