Re: Printing Enum Variable Re: Linux World

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

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
-------------------------------------