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,5e12faea1fbd9314
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: Another aspect of comments and coding standards
Date: 1996/06/07
Message-ID: <dewar.834154978@schonberg>#1/1
X-Deja-AN: 159058635
references: <9606061336.AA03923@most> <dmarshalDsLuu3.Aqr@netcom.com>
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-06-07T00:00:00+00:00
List-Id: <comp.lang.ada>


Dave Marshall says

"For instance, I am a little bit uncomfortable with the use of the
anonymous subtype used in the membership test."

This is a very good point, particularly applicable to the case of
enumeration types. A weakness in Ada is that enumeration types are
always ordered, and you cannot hide this ordering from a client.

Logically what is often done is to arrange a set of enumeration values
in order so that subtypes dfining appropriate subclasses
can be defined as part of the same abstraction.

However, there is no way, other than coding standards, to avoid a client
noticing that today three values happen to be contiguous and replacing

   if a = enum1 or a = enum2 or a = enum3 then

by

   if a in enum1 .. enum3 then

Now of course you have a maintenance headache, because at the abstraction
level the specific order of the enumeration literals was not defined.
A reasonable coding standard is to absolutely forbid ranges in membership
tests for enumeration types (there is no similar objection for integer
types, this comment applies only to enumeration types).