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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ca9eef4d5e2078ea X-Google-Attributes: gid103376,public From: Stephen Leake Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/10 Message-ID: <348F13DA.FC6@gsfc.nasa.gov>#1/1 X-Deja-AN: 297034867 References: Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Reply-To: Stephen.Leake@gsfc.nasa.gov Newsgroups: comp.lang.ada Date: 1997-12-10T00:00:00+00:00 List-Id: Tucker Taft wrote: > > > > So in retrospect, I believe enumeration representation > clauses in Ada are a mistake. If a user wants to name > particular values, they should simply use named integer > constants, or perhaps better, named private-type constants. They can build > up various maps of their own if they want to translate to/from some kind > of "holey" representation from/to a contiguous representation. I'm fairly sure that in most of the code I've written, if I supply a rep clause for an enumeration type, I use it mainly as parameters to and results from imported functions (Win32 comes to mind), but not as an array index or with succ/pred. Often the results are used in case statements. I guess this maps well to named private-type constants, where the full type is simply an integer. However, it loses the completeness check on case statements, which is always useful. Maybe we could introduce a "bag" type (avoiding the highly overloaded moniker "set"), which would not have pred/succ semantics, but would provide completeness checks for case statements? > -- > -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ > Intermetrics, Inc. Burlington, MA USA -- - Stephe