Re: Printing Enum Variable Re: Linux World

[Ehud Lamm <mslamm@mscc.huji.ac.il>]

On Fri, 5 Mar 1999, Nick Roberts wrote:

> | There is a point of view in the OOP community that says that enumeration
> | types arean 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.

I am not sure I agree with this "OOP community" view. It may be useful to
note that in some sense all enumeration types are one type. The type of
data items can be seen as a generic parmater of this type (the type itself
supports things like succ and pred). Maybe this will help some one to see
that enumeration types should not be extened by adding values, but by
adding operations. This is possible with enumeration types in the smae way
in which it is possible for other types (like integer of tagged types). 

I am not sure this short explanation is enough to make my view clear...

> 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 isabstract tagged ...;
> 
>  function Traffic_May_Pass (State: in Traffic_Light_State) return Boolean
> is abstract;

This raises a different issue all together. When is it smart to model
using data structres, hiding the procedural nature of the problem, and
when should we model the procedural nature directly. Which abstraction
should we choose?

Let me make it concrete.

Consider generic menu procedure I posted. Now suppose we wanted to enhance
it so that the menu routine will call the appropriate handler according to
the user choice. We can do this in two ways:
1. Supply the menu routine with an array of pointers to procedures,
indexed by menu_choice. This allows us to simple call the apropriate
handler. We can make this array a generic parameter, or we can supply it
as a run time paramter. 

2. We can add a generic procedure paramter, which will accpet a
menu_chioce and decide what to do with it. This solution is usable in
Ada83 too. 

Which is better? It depends. The first choice has many advantages, but
lacks some flexibilty, which is quite eacy to achieve using the second
approach. I do not want to elaborate too much, since many might find the
obvious. Perhaps I'll summerize this example as a case-study some day.  
 (Other design choices exist, like making the menu a tagged type with
dispatching operations...)

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il