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,b0d68c502c0ae6 X-Google-Attributes: gid103376,public From: Ehud Lamm Subject: Re: Printing Enum Variable Re: Linux World Date: 1999/03/06 Message-ID: #1/1 X-Deja-AN: 451867896 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> <7bpn1v$3kd$1@plug.news.pipex.net> Content-Type: TEXT/PLAIN; charset=US-ASCII Organization: The hebrew University of Jerusalem Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-03-06T00:00:00+00:00 List-Id: 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