agesen@Neon.Stanford.EDU (Ole Agesen) (08/31/90)
In article <141522@sun.Eng.Sun.COM> pallas@red-dwarf.Sun.COM (Joseph Pallas) writes: >>All this, however, still leaves the original question unanswered: >>"WHY SHOULD CLASSES BE OBJECTS?" I would also like to know! > >Why not? Object-oriented programming languages have the manipulation >of objects as their foundation. So, if you want to manipulate >classes, make them objects. Let me try to say why I think classes and objects should be considered different. This is to some extent a matter of perspective. I belong to the "modelling camp", i.e. I consider object-oriented programming to be modelling. A program EXECUTION consists of a set of interacting objects and it is a physical model of a part of the real world. The objects (and the actions they perform) reflect real world phenomena (and the actions they perform). The program execution is generated according to a prescription, the program, which at the same time is a description of the real world part. Real world phenomena are characterized by means of concepts, which have classes as their model system counterpart. So objects reflect phenomena, but classes reflect concepts. Phenomena have substance that change through interactions. Objects model this by encapsulating state that change as a result of methods being invoked. In contrast, concepts have no substance and perform no actions, hence their model system counterparts, classes, should not have state or define methods. Conclusion: classes are not objects since they encapsulate no state, and do not perform action sequences. More details can be found in: O. L. Madsen and B. Moeller-Pedersen: "What object-oriented programming may be - and what it does not have to be" (in ECOOP'88). Admitted: Smalltalk suggest a somewhat different perspective on programming. This results in flexibility, but also in some conceptual problems that are not found above, most notably the meta class regression (classes are instances of meta classes that are instances of ...) Ole >P.S. Is there any easy way to get hold of a copy of this? >>"Persistent and Shared Objects In BETA"; O. Agesen, S. Froelund, M. H. Olsen; >>Masters thesis, Daimi IR-89; April 1989, Computer Science Department, Aarhus >>University, Denmark. Try asking Mr. Elmer Sandvad, ess@mjolner.dk, but no promise!
kasper@iesd.auc.dk (Kasper Osterbye) (08/31/90)
In article <1990Aug30.222809.291@Neon.Stanford.EDU> agesen@Neon.Stanford.EDU (Ole Agesen) writes: From: agesen@Neon.Stanford.EDU (Ole Agesen) Summary: O-O Programming is modelling In article <141522@sun.Eng.Sun.COM> pallas@red-dwarf.Sun.COM (Joseph Pallas) writes: >>All this, however, still leaves the original question unanswered: >>"WHY SHOULD CLASSES BE OBJECTS?" I would also like to know! > >Why not? Object-oriented programming languages have the manipulation >of objects as their foundation. So, if you want to manipulate >classes, make them objects. Let me try to say why I think classes and objects should be considered different. This is to some extent a matter of perspective. I belong to the "modelling camp", i.e. I consider object-oriented programming to be modelling. A program EXECUTION consists of a set of interacting objects and it is a physical model of a part of the real world. The objects (and the actions they perform) reflect real world phenomena (and the actions they perform). The program execution is generated according to a prescription, the program, which at the same time is a description of the real world part. Real world phenomena are characterized by means of concepts, which have classes as their model system counterpart. So objects reflect phenomena, but classes reflect concepts. Phenomena have substance that change through interactions. Objects model this by encapsulating state that change as a result of methods being invoked. In contrast, concepts have no substance and perform no actions, hence their model system counterparts, classes, should not have state or define methods. Conclusion: classes are not objects since they encapsulate no state, and do not perform action sequences. More details can be found in: O. L. Madsen and B. Moeller-Pedersen: "What object-oriented programming may be - and what it does not have to be" (in ECOOP'88). Being from the same tradition as Ole, considdering OOP as modeling, I must admit that I think he is utterly mistaken. Metaclasses are not used enough when we are doing modelling. The following example is not one of mine, but taken from Patty Maes's paper in OOPSLA-87. Assume we are writing a simulation program (prime examples where modelling are important). We are dealing with a car wash. Sure we build a class that represents cars. But only things that has to do with the representation of the physical car should be represented in the car-class. But very often one sees cars that can print them selves and note when they entered a queue and when they left etc. I must admit that I never saw a car print itself. On other example is that classes as objects is a beautifull model for program environments. Here the objects one manipulate are the classes. I know that one can always argue whether or not one wants to support this understanding directly in the language (as attempted in Smalltalk), or to do it by having an environment where the programs are not first class. Admitted: Smalltalk suggest a somewhat different perspective on programming. This results in flexibility, but also in some conceptual problems that are not found above, most notably the meta class regression (classes are instances of meta classes that are instances of ...) I see no conceptual problems in Smalltalk that is not in other languages. In Beta, C++, Simula, Eiffel etc. there is a hardcoded meta-class called the compiler. This is a very efficient way to stop the meta class regression. In Smalltalk, they have included a few levels of meta classes, but they too have stopped at some level. Seen from a philosofical perspective, Goedels theorem states that a model of any interest can not be complete and consistent at the same time. Therefore, we need a meta level, to describe that classes are, and we need a meta-meta level to describe what meta-classes are and so forth. So if we want a programming paradigm that can be used for modelling all kind of systems, it has to support infinite meta levels. This can ofcause not be done, but what I am trying to say is that one can not claim that "from a modelling perspective, meta classes are not needed", rather the opposite I would say. In both Smalltalk and Beta, one can say: "from practical experience this seems to work" Ole --Kasper -- Kasper Osterbye Internet: kasper@iesd.auc.dk Institute for electronic systems UUCP: ...!mcvax!iesd!kasper Fredrik Bajers vej 7, 9220 Aalborg DENMARK. (W) +45 98 15 85 22 (H) +45 98 37 30 65
oscar@cui.unige.ch (Oscar Nierstrasz) (09/01/90)
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 ---------------------------------------------------------------------
caseau@maya.bellcore.com (Yves J Caseau) (09/03/90)
Here is my 0.02 cents contribution on this subject. I use a rather peculiar
model of object-oriented programming where classes are ONLY used for
"classification" (set organization). Behavioural description is done by
attaching type signature to operations or relations. In this context, the
actual question could be generalized to
What good is reflection?
i.e. Why classes as objects, methods as objects, and so on
My arguments are as follow:
(1) object-oriented programming is a good technique for developing modular
and extensible software. The main reasons are the one you can include
here (nice abstract interface, inheritance, set taxonomy,....)
(2) Using OOP for knowledge representation imply designing an extensible
system as opposed as a "swiss-army-knife"-like language. I need in my
applications to extend the language with new features (eg: add history
management to instantiation) and to reason on the language's objects
(eg: describe the mathematical properties of methods to include them in
the inference engine).
So a natural solution is to apply the technique (1) to the problem (2). If
classes are objects, you can easly:
- complete their description through new methods. If you define a set
operation package (such as an extended type system), you'll be happy
to include classes in it.
- create your new kind of classes (meta-class) to add necessary feature.
I had a practical example where I needed to implement dependencies
between objects are some of their slots (i.e. a SSN uniquely determine
a person). Doing by defining a new sort of class seems to me the
most generic (and therefore, re-usable) way.
This is rather independant of the model that you use. As far as dogmatic points
are concerned (class as a way to encapsulate behaviour), I really think that
class have a behaviour that should be encapsulated. In my model (the LAURE
language) a class is nothing more that a set defined in an inclusion lattice;
and the set of all classes is definitely useful, so classes are objects.
-- Yves Caseau
caseau@bellcore.com
PS: LAURE is an acronym for LAure is Universally REflective