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.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b0d68c502c0ae6 X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: Printing Enum Variable Re: Linux World Date: 1999/03/05 Message-ID: <7bpn1v$3kd$1@plug.news.pipex.net>#1/1 X-Deja-AN: 451727597 References: <7bfc2n$jl9@dfw-ixnews5.ix.netcom.com> <7bhh26$r7c$1@remarQ.com> <36DCAC1F.430E2C5E@aasaa.ofe.org> <7bk4v8$kl8$1@remarQ.com> <36DDA761.7B4E8099@aasaa.ofe.org> <7bkrmm$ao1$1@nnrp1.dejanews.com> <7bpevu$frn@dfw-ixnews12.ix.netcom.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom) Newsgroups: comp.lang.ada Date: 1999-03-05T00:00:00+00:00 List-Id: Richard D Riehle wrote in message <7bpevu$frn@dfw-ixnews12.ix.netcom.com>... [...] | Enumeration types also carry the potential for abuse. I recall | a programmer who had a package specification with an enumeration | type where the set of values spanned three pages of source code. I think it's interesting to note that the (notional) declaration of the Character type (RM95 A.1) is pretty big, and a declaration of Wide_Character would span more than three pages! I suppose it's also interesting to note that these types can't be declared by a normal Ada declaration (the control characters are unrepresentable). | If enumeration types are to be on the idiom list, they should be | accompanied by a set of guidelines. One of the problems we are | trying to solve with object-oriented programming and child library | units is the extension of existing code without performing "open | heart surgery" on it. Heavy use of enumeration types can result in | cracking open existing code to perform such extensions. | | Some of the guidelines I follow, and counsel my clients to follow, | 1) only use enumeration types when there is a well-known limit to the | set of values. 2) Use them when there is a clear requirement for an | ordered set, 3) Use them for identifying types that have a small | set of values (e.g., Location is (Front, Back);). The canonical example -- I suppose -- being the type Boolean. | There is a point of view in the OOP community that says that enumeration | types are an artifact of an obsolete style of programming. That is, | an enumeration type, because it is not extensible and cannot be | further specialized, is antithetical to OOP. Although I find this | viewpoint a little too narrow for my taste, one could make a very | good case to support it in many situations. In Ada, tagged types -- possibly empty -- can be used like extensible enumeration types (which is presumably partly why the original idea of extensible enumeration types was rejected). The syntax is, perhaps, slightly clumsy for this use, sometimes. Compare: type Traffic_Light_State is (Red, Amber, Green, Red_And_Amber); Traffic_May_Pass: array (Traffic_Light_State) of Boolean := (Red | Red_And_Amber => False, Amber | Green => True); If you wanted to added a new state (blinking amber, say), you would have difficulty in two ways: firstly, you can't extend the enumerated type without performing 'open heart surgery' on the code; secondly, the question of whether traffic may pass may need to be qualified (by whether there is a pedestrian crossing the road), so that you can't just extend the array, you have to make some more extensive changes to the program's logic. Now consider: type Traffic_Light_State is abstract tagged ...; function Traffic_May_Pass (State: in Traffic_Light_State) return Boolean is abstract; then: type Red_Light_State is new Traffic_Light_State with ...; function Traffic_May_Pass (State: in Red_Light_State) return Boolean; where the function body would presumably just return False, and so on for the other states. Now, a new state can be added easily, and it may be possible to add logic in the body of the Traffic_May_Pass function to decide whether a pedestrian is crossing the road or not before giving traffic permission to pass. However, it remains difficult to code, in an easily extensible way, which state comes first or last (as in the attributes First and Last), or to iterate over them (as in the attributes Pred and Succ), since extensibility means there is no clear 'last' element, and no clear 'next' for each one. Like most good ideas, this idea is ludicrous when taken to the extreme. Would it make sense to implement Boolean as a tagged type? Or Character, or Wide_Character? (Perhaps it _would_ make sense for Wide_Character or a similar type, but I'm dubious.) ------------------------------------- Nick Roberts -------------------------------------