From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c3a7c1845ec5caf9 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Equality operator overloading in ADA 83 Date: 1997/05/05 Message-ID: #1/1 X-Deja-AN: 239569871 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <01bc54ef$2621d680$LocalHost@xhv46.dial.pipex.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-05-05T00:00:00+00:00 List-Id: In article , Robert Dewar 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