A Uniform Model for Object-Oriented Languages Using the Class Abstraction

A Uniform Model for Object-Oriented Languages Using The Class Abstraction

Jean-Pierre BRIOT LITP, Universite Paris-6 4 Place Jussieu Paris, 75005

mcvax!inria!litp!jpb Pierre COINTE Rank Xerox France 12 Place de !'IRIS La Defense, 92071

mcvaxlinria!litp!pc

Object-oriented programming is built from the class model, introduced in the language Simula-67. In Simula, a class is a way to describe an abstract data structure. Active objects may be dynamically created from the class description by instantiating the variables specified by the class. Such objects are called instances of the class.

B. Is a Class an Object?

.. With respect to Simula, Smalltalk abandons static scoping, to gain flexibility in interactive use, and strong typing, allowing it to implement system introspection and to introduce the notion of metaclasses" UJ.

The object paradigm is set, and is now distinct from abstract data types systems. The Smalltalk language has evolved from Smalltalk-72 [7] to Smalltalk-80 in order to give the user some control on classes. Smalltalk-76 [9] is the first language to consider a class as an object itself, i.e., instance of a special class, called a metaclass. However, besides an uniformity wish 2 , a class is not a true object. Its structure is not fully specified at the meta-level but remains at the implementation level. Only the behavior of classes, i.e., the way they react to message passing, is specified at the meta-level, through this unique metaclass, called Class.

C. Smalltalk-80' Metaclasses are Not a Full Answer

A unique metaclass imposes a unique behavior to all classes. For this reason, Smalltalk-80 [8] introduced the metaclass concept to allow dist,inct behaviors for different classes. Each class now has its own metaclass. This facility is mainly used to (re)define the instantiation method, to initialize class variables, or to hold predefined examples. However, Smalltalk-80 metaclasses are implicit (they are implicitly created from the class description) and virtual (they cannot be used as true classes, e.g., being explicitly instantiated). Consequently metaclasses introduce such a conceptual gap in the understanding of Smalltalk-80 that Borriing proposes to drop them:

..In our empirical studies, metaclasses were regarded as the most significant barrier to learn ability by both students and teach­ ers. We propose that they be eliminated. We have explored var­ ious alternatives to metaclasses, such as the use of prototypes. However, for DeltaTalk we simply propose that the language re­ verts to the situation in Smalltalk-76. Every class would be in­ stance of class Class· [£}.

2 ·one way of dating the Smalltalk philo&ophy u to choo&e a &mall number of general principle& and apply them uniformly" [10].

Abstract

One of the main goals of object-oriented languages is to unify their universe: "every entity of the language is an ob­ ject." The class concept, however, usually does not follow this wish: a class being not a real object, i.e., created from a class. The metaclass concept introduced in Smalltalk80, attempts to give classes a first class citizenship but complicates the instantiation scheme without solving its fundamental limitations: the only partial specification of the class at the metaclass level, and the fixed number of meta-levels.

Some more recent approaches, as in Loops and then CommonLoops, tend towards a better unification, but re­ veal the same limitations. We propose to go one step further and present an ultimate new model for an opti­ mal simplification of the class/object concept, while keep­ ing the class abstraction. In this model, implemented by ObjVlisp 1 , every object is an instance of a class, and a class is a true object fully specified at the meta-level. A meta­ class is a true class inheriting from another one. Because . ObjVlisp is built on a reflective architecture; the user has uniform access and.control to all the levels of the language: class level, metaclass level. .. He can add new levels and the metaclass links can be created indefinitely.

Finally, we suggest to clarify the Smalltalk terminology with a new definition for class variables: the instance vari­ ables of a class - treated as an object - become the class variables of this class, explicitly expressed at the metaclass level.

I Class versus Object

This paper deals with the instantiation mechanism used by object-oriented languages which organizes objects along the class abstraction.

A. Class and Instantiation

·A central new concept in SIMULA 67 is the 'object'. An ob­ ject is a self-contained program {block instance), ,having its own local data and actions defined by a 'class declaration'. The class declaration defines a program {data and action} pattern, and ob­ jects conforming to that pattern are said to 'belong to the same class' · {6}.

lThis research was supported by the "Object group· of the Greco de Programmation, CNRS, France.

We do not agree with Horning's view. It seems to us that metaclasses do add great expressive power to OOLs and that it is really worthwhile to find a correct defini­ tion for them. We need metaclasses to develop friendly open-ended systems [5] and we believe that the fundamen­ tal problem with Smalltalk remains the impossibility to explicitly specify classes as instances of true classes. In or­ der to solve this deficiency and to simplify the Smalltalk-80 model we propose to unify classes and metaclasses.

II Unification

We claim that a class must be an object with a first class citizenship allowing greater clarity and expressive power.

A. Is Every Object a Class?

There are still classes and non-class objects in our model. The "non-class" objects are called terminal instances, they are fully instantiated and are not abstractions like classes. B. How Many Object Types?

There are two kinds of objects (classes and terminal instances). There is no type distinction however. A class and a terminal instance only differ through their respective classes. For instance, a class will accept the new message to create an instance of itself, but a terminal instance will reject it.

C. Metaclasses are True Classes

A class of classes is called a metaclass, it specifies the structure and the behavior of classes. The first primitive metaclass in the language is called CLASS and owns the new primitive method for instantiation. Any class declared as a subclass of CLASS inherits its ability to specify and control classes (e.g., the new method), and thus becomes a metaclass. Consequently, metaclasses are true classes and also true objects.

D. Creation of a Class

This unification induces a simplification of the instan­ tiation and inheritance concepts but imposes that they be used simultaneously. We can create object with inheritance (classes and metaclasses) or without inheritance (terminal instances). For instance a metaclass is created as the sub­ class of another one (as an "ultimate" subclass of CLASS).

The distinction between metaclasses, classes and termi­ nal instances is only a consequence of inheritance and not a type distinction. There is now only one type of objects in the model.

III The Unified Model

A. Structure of an Object

A class describes the structure of a (potential) set of objects through an ordered collection of instance variables. The first instance variable- called isit - is automatically inherited from the OBJECT class and refers to the name of the class of the object (each object is the instance of a class).

As an example the POINT class, describing 2D points specifies the following instance variables: <isit x y>

An instance of this POINT class, e.g., the point 10@20, owns the values associated to the instance variables speci­ fied by its class: <POINT 10 20>

A set of procedures (called methods), usable by any of its instances, is also specified by the class as we see below.

B. Structure of a Class

H we want to define a class, we need to know the in­ stance variables describing a class. They are specific to our model: <iait name supers Lv methods>

Because it is convenient to have named classes, name denotes the name of the class.

The list of the names of the direct superclasses from which the class will inherit is denoted by super.

The list of instance variables that the class specifies is denoted by Lv.

The set of methods held by the class expressed in a P-list way, with pairs <selector-name . >.-expression> is denoted by methods.

The isit instance variable belongs to the OBJECT class, the most general class in the model. In contrast to other usual instance variables, the corresponding value is auto­ matically supplied when creating the object.

We can now describe the structure and the behavior of a class through this set of instance variables: a class has at last become a real object.

C. The POINT Example

To illustrate our model, we present its Lisp implemen­ tation called ObjVlisp. We define POINT as a subclass of the OBJECT class by instantiating the first metaclass CLASS. A CommonLisp syntax is used for specifying the values as­ sociated to the instance variables of the class-receiver :

(send CLASS 'new

:name

:supers

: i_v

:methods

'POINT

'(OBJECT)

· (x y)

'(x (). 0 x)

x: (>. (nx) (aetq x nx)) ) )

Then we create an instance of POINT, using the same new message: (send POINT 'new :x 10 :y 20)

IV Reflection

CLASS is the first primitive object. It will recursively create all other objects. CLASS needs to be an instance of some class as any object of the model. To prevent an infinite regression (we need the class of CLASS, and the class of this class ... ) the usual technique in OOLs is to circularize the instantiation tree by adding a loop at its root. The simplest way is to set this loop at the CLASS level, i.e., by declaring CLASS as its own instance (and class).

A. Self Pattern Matching of CLASS

The previous statement severely constrains the struc­ ture of CLASS. The instance variables specified by CLASS m~t mate~ the corresponding values held by CLASS itself, ash 1ts ow~ 1nstance. Below are the instance variables and t e assoc1ated values :

ilit name

1upen Lv methoda

CLASS CLASS (OBJECT)

(ioit name oupen Lv methoda)

(new (> ·.. ))

Note that the value associated to the instance variable Lv is exactly the list of instance variables itself. This self pattern-matching illustrates the circular definition of CLASS.

B. The Golden Braid

In order to implement our model in a reflective way, we need a "bootstrap" [5]. We first create, on the Lisp level, a skeleton of CLASS owning the new method. Then we create, on the ObjVlisp level, the class OBJECT, root of the inheritance tree :

'OBJECT ·o · (isit) (send CLASS 'new :name :aupera :Lv :methods '(class (A() isit) .. ) )

Then we redefine CLASS by a self-instantiation using the values presented above :

(send CLASS 'new :name 'CLASS :supers '(OBJECT) : Lv ' (name supers Lv methods) :methods ' (new (A Lv·

(make- instance . .. ))) )

Aft~r the bootstraping process, the system owns only the CLASS and OBJECT classes and the instantiation tree is exactly like the Smalltalk-76 one. But, as demonstrated in [ 3], the uniformity and the explicit definition of the objects CLASS and OBJECT open an immense variety of possibili­ ties.

C. Unicity versus Genericity

The model we present is optimal in its simplicity and generality. The unicity of the new method reflects the unique type of objects: real instances of classes. On the other hand, because of inheritance there are two kinds of object creations. Thus the new method is not fully generic.

When creating an object, inheritance applies to classes but not to terminal instances. As a consequence, the make­ instance primitive needs to discriminate between classes and terminal instances.

In order to explicit these two ways of creating objects (with or without inheritance) and regain genericity of the new method, we may use another primitive object in the model, called METACLASS, owning the new method with inheritance (creating classes). Then CLASS will own an­ other new method without inheritance (creating terminal instances): This second alternative is similar to the Loops kernel [1], augmented with the full specification of classes at the meta-level. The disadvantage is the increased com­ plexity necessary to gain genericity for the new method. It is very easy to extend our model towards this second alter­ native, in that sense we believe our model is more general and simpler to understand and manipulate.

D. Indefinite Meta-Levels

We may extend the system with the same tools that were used to create it: · instantiation and inheritance. For instance, we can specify and control two new levels of metaclasses by first defining the SET class (whose instances memorize the list of their instances), then the MPOINT class (whose instance, the POINT class, memorizes its instances and parametrizes the display character c) :

(send CLASS 'new :naae 'SET :supers '(CLASS) :i_v '(listOfinstances)) (send SET 'new :naae 'MPOINT :supers '(SET) : i_v '(c)) (send NPOINT 'new :naae 'POINT :supers '(OBJECT) :i_v '(x y) : c ''.'')

V Class Variable

We propose an alternative to the Smalltalk class variables. The principle is to extend the scope of the instance vari­ ables of a class to each of its instances. Then the class variables are defined at the metaclass level a8 simple in­ stance variables of the class treated as an object.

A. The Polygon Problem

Let us develop the Polygon construction to illustrate this idea. The problem is to represent the (regular) Poly­ gon abstraction and the Square and Hexagon sub-abstract­ ions. The methodology of Smalltalk-80 leads to use the class hierarchy to define, first the Polygon class, then its Square and Hexagon subclasses.

B. The Smalltalk-80 Solution

Each polygon will be defined by its location (the first vertex) and the length of any of its sides. Consequently location and length will be defined as the instance vari­ ables of Polygon treated as a class. The problem then, is to parametrize the number of sides: 4 for a square, 6 for a hexagon, undef for a polygon. H we define nSidea as a class variable of Polygon, nSidea will be inherited by Triangle and Square because they are sub-classes of Polygon.

But in Smalltalk the inheritance for class variables does not follow the inheritance for instance variables. Class vari­ ables are used to share knowledge between instances of a class hierarchy. For example, if the new method is rede­ fined to add the newly created instance of a class inside a Collection's class variable, the instances of its subclasses will also be memorized. In the same way, each square or hexagon would share the same number of sides!

Because class and metaclass hierarchies are parallel, the unique solution is to define nSidea as an instance vari­ able of Polygon treated as an object, i.e., at the "Polygon claaa" level. Nevertheless, to access the value of nSidea from an instance of Polygon (or Square and Hexagon) we have to explicit at the metaclass level two "read-write" methods controlling this metavariable 3 · To define "6 sided" polygons we will use the transmission :

Hexagon initialize: 6

C. The ObjVlisp Solution

The "Polygon scheme" is believed to be quite general when applying the class abstraction to the knowledge rep­ resentation field. To capture it, we have decided to define the ObjVlisp class variables at the metaclass level, real­ izing a "global environment" shared by all the instances of a class and following the inheritance rules of instance variables. Unlike Smalltalk-80, our class variables are in­ herited but not shared by the subclasses. Consequently, here is our alternative version of the Polygon example :

3 Here are these two methods held by Polygon cla8B: Polygon class> >nSic'les

fnSides Polygon claas>>initialise: numberOfSidea tnSides+- numberOfSides

(send CLASS 'new :name 'METAPOLYGON :supers '(CLASS) : Lv ' (nSides) (sendMETAPOLYGON 'new :name 'POLYGON : supers '(OBJECT) : Lv '(location length) :methods '(display (A() ... ) .. . ) :nSides 'undef) )

METAPOLYGON is a subclass of CLASS, thus it is a meta­ class. The creation of POLYGON explicits the instantiation of the class variable nSides. Then we can define new classes of polygons, with distinct values of nSides, by defining them as inheriting from POLYGON. As an exam­ ple the SQUARE and HEXAGON objects are the classes of "4 sided" and "6 sided" polygons :

(send METAPOLYGON 'new :name 'SQUARE :supers '(POLYGON) :nSides 4) (send METAPOLYGON 'new :name 'HEXAGON :supers ' (POLYGON) :nSides 6) (send SQUARE 'new : location (send POINT 'new :x 100 :y ·200) : length 20)

Every object has access to its own environment as well as the environment of its class. Consequently nSides is bound at two levels: class and instances methods 4 · The previous instance of SQUARE has access to the bindings of the instance variables of its class with the associated values it owns, i.e.: (isi t . SQUARE) (location . 100«1200)

(length . 20). But it also has access to the bindings of the instance variables of its metaclass with the associated values that SQUARE owns, thus gaining the value of the (meta)instance variable: (nSides . 4).

D. Towards a New Terminology

The problem with the terminology developed by Small­ talk-SO is the non-symmetry between the instance and the class levels. We agree with the instance methods and class methods definitions because they respectively express the behaviors of the instances and then the behavior of a class as an object. On the other hand, we are confused by the class variable definition which does not define the field of a class as an object but defines a knowledge shared by all its instances.

4 To illustrate this point, here are the definitions of the two display methods (Srnalltalk & ObjVlisp) drawing every class of polygons and held by POLYGON :

aPen+- Pen new place: location. (oelf clan nSideo) timeeRepeat : [aPen go: length ; turn: 360 I I (oelf clau nSideo)] (~ () (let ((aPen (oend (oend Pen 'new) 'place: location))) (repeat nSideo (oend aPen 'go: length) (send aPen 'turn: (/ 360 nSideo)))))

We propose to keep the term class variable BUT to use it for a different meaning. A class variable becomes an instance variable of the class treated as an object. To rename the Smalltalk term class variable, we suggest the term sharedClass variable.

VI Conclusion

We have presented here a new model for object-oriented programming. This model unifies class and object con­ cepts. A class is now a true object, fully specified at its meta-level. The primitive metaclass of the model, called CLASS, is described and created in a circular way, as an instance of itself. This class is the root of the instantiation tree whose depth is potentially infinite and the user has now an uniform control on every meta-level.

Acknowledgments We thank Jean-Francois Perrot, Kris Van Marcke and Henry Lieberman for their helpful com­ ments.