Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!iesd!iesd.auc.dk!kasper From: kasper@iesd.auc.dk (Kasper Osterbye) Newsgroups: comp.object Subject: Re: Should classes be objects Message-ID: Date: 31 Aug 90 09:58:54 GMT References: <141522@sun.Eng.Sun.COM> <1990Aug30.222809.291@Neon.Stanford.EDU> Sender: news@iesd.auc.dk (UseNet News) Organization: Mathematics and Computer Science, University of Aalborg Lines: 83 In-reply-to: agesen@Neon.Stanford.EDU's message of 30 Aug 90 22:28:09 GMT 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