Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!cernvax!chx400!ugun2b!cui!oscar
From: oscar@cui.unige.ch (Oscar Nierstrasz)
Newsgroups: comp.object
Subject: Re: the need for classes as objects (was: Runtime Class Creation)
Keywords: Dynamic class creation, dynamic linking, ROTTETANG.
Message-ID: <3240@cui.unige.ch>
Date: 30 Aug 90 09:27:35 GMT
References: <2259@esquire.UUCP> <9959@goofy.Apple.COM> <1990Aug29.025227.19172@Neon.Stanford.EDU>
Organization: University of Geneva, Switzerland
Lines: 72

agesen@Neon.Stanford.EDU (Ole Agesen) writes:

>I think Mr. Susser's example is a good illustration of why it is important
>to be able to CREATE NEW CLASSES AT RUNTIME.

	<stuff deleted>

>All this, however, still leaves the original question unanswered:
>"WHY SHOULD CLASSES BE OBJECTS?" I would also like to know!

I think the only way to properly answer this question is to first step
back and consider the question: "Why should *anything* be an object?"

Here are some of my favourite reasons:
- to encapsulate behaviour (system modularity)
- to encapsulate data (modelling concepts)
- to factor out functionality (reusability)

In each case, you make something an objects because you want to be
able to do something with it:
- ask it to perform a servuce
- store, recall or modify information
- combine it with other objects to create something new

Now, what is a class?  Basically it is a template for making objects:
a "cookie cutter" that can be modified and extended to make a variety
of different kinds of cookies (by choosing different initial values,
binding class/type parameters, and by modifying or extending inherited
behaviour).

So, what are good reasons for wanting a class to be an object?

1. to view and manipulate the definition of the class (data encapsulation)
2. to model sharing of behaviour between classes (factoring functionality)
3. to extend or alter the definition in a controlled way
	(behavioural encapsulation)

The first and the second are convenient for creating classes at run-time.
Objects are just a convenient mechanism for encapsulating class descriptions.
(Aside: is there a real need to distinguish between a class and the source
text of the class, i.e., the class description?) It is not hard to come up
with other ways of adding new classes, but they are not so appealing
(e.g., sending a message containing the class description as a message to
a "system" object which, as a side effect, creates the new class.)

The third reason is more interesting.  Suppose we wish to dynamically
change the behaviour of an entire class of objects (i.e., the set of
instances).  This can be the case in information systems containg
large numbers of persistent objects that encapsualate primarily
information but also some behaviour (e.g., constraints on how the
information may be accessed and modified).  When changes occur in the
requirements of the system, we would like to be able to change or extend
classes without losing the instances.

There has been a lot of work in the past few years on so-called
"reflective" objects (objects that can change their own behaviour),
most of it motivated by artificial intelligence (see recent OOPSLAs etc.).
I have not seen so much work on applying this idea to evolving systems
(outside of the work by Kim et al. at MCC on schema evolution in
object-oriented databases), but this seems to me one of the most
compelling reasons for wanting classes to be objects.

Other opinions?

Oscar Nierstrasz

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