Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!apple!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!cernvax!chx400!ugun2b!cui!oscar From: oscar@cui.unige.ch (Oscar Nierstrasz) Newsgroups: comp.object Subject: Re: Should classes be objects Keywords: Garfield Message-ID: <3245@cui.unige.ch> Date: 31 Aug 90 17:34:22 GMT References: <141522@sun.Eng.Sun.COM> <1990Aug30.222809.291@Neon.Stanford.EDU> Organization: University of Geneva, Switzerland Lines: 52 agesen@Neon.Stanford.EDU (Ole Agesen) writes: >Conclusion: classes are not objects since they encapsulate >no state, and do not perform action sequences. Well, it all depends on what you mean by a "class." In fact, there are many complementary views that take on interesting aspects when you allow classes to be objects: 1. a class as a "cookie cutter" for objects (the "intension") 2. a class as the repository of shared behaviour 3. a class as a set of instances (the "extension") 4. a class as a manager of its instances The first can be useful for instantiating objects. Construct a "class" object, and send it a message to create instances. Here the "state" of the class object is only of interest while you are (iteratively?) defining it. Once it is complete, there is no further interest in having it as an object. The second scenario is interesting if instances must go to the class object to access the shared behaviour a la method lookup in smalltalk or delegation in prototype based languages. In this case the class does have a state, namely the currently defined shared behaviour. If this is changed, the behaviour of all instances (magically) changes. Obviously this must be done in a controlled fashion! (A less exotic use is for class objects to maintain so-called "class variables" as in Smalltalk.) The third scenario is interesting in situations where you want to iterate over all instances or if you want to pose queries, as in object-oriented databases. The "state" is the current set of instances. The fourth situation is the natural extension of the second and third: if you want to change the behaviour of all instances in some radical way (a la schema evolution as in Orion) then something must decide what are valid ways to change this behaviour and must assume responsibility for maintaining consistency of the instances (e.g., when dropping or adding instance variables). [This is, I think, what Mario is talking about when he mentions the need for classes as objects when instances persist through evolutionary changes in the applications.] Oscar --------------------------------------------------------------------- Dr. O.M. Nierstrasz E-mail: oscar@cuisun.unige.ch Centre Universitaire d'Informatique Tel: 41 (22) 787.65.80 12 rue du Lac, CH-1207 Geneva Fax: 41 (22) 735.39.05 SWITZERLAND Home: 41 (22) 733.95.68 ---------------------------------------------------------------------