Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rutgers!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: johnson@m.cs.uiuc.edu
Newsgroups: comp.object
Subject: Re: Runtime Class Creation (was: th
Message-ID: <77500055@m.cs.uiuc.edu>
Date: 31 Aug 90 03:39:00 GMT
References: <141522@sun.Eng.Sun.COM>
Lines: 40
Nf-ID: #R:sun.Eng.Sun.COM:141522:m.cs.uiuc.edu:77500055:000:2487
Nf-From: m.cs.uiuc.edu!johnson    Aug 30 22:39:00 1990


>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. 

I have an optimizing compiler and a operating system, both with an
object-oriented implementation.  It seems to me that you have to
stretch things a little to say that either is modeling the real world.
On the other hand, I've found that it is a big advantage to try to
make the program as much like the theory as possible, i.e. the program
is a representation (or a model) of the theory of compiling, virtual
memory, etc.  I think that I generally agree that programs should be
models, but "real world" and "real world phenomena" is definitely too 
restricting.  Computer scientists have a tendency to forget that the
purpose of computers is to solve problems for their owners, but one
should not go to the other extreme and forget that computers spend a
lot of time performing activities like processor scheduling and type
checking that are not very closely related to the owner's ultimate needs.

>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.

But we can model concepts, too.  We can classify concepts, we can
combine concepts, we can change concepts as our ideas improve, we
can add new concepts and forget old ones.  Some concepts imply other
concepts, while some concepts contradict each other.  It seems
reasonable to me that concepts could have components, and that there
could be relations between concepts.  Thus, I don't think that the
previous paragraph proves that classes should not be objects.

Ralph Johnson - University of Illinois at Urbana-Champaign