Computational. Reflection Class based Objectkented Languages
JacquesFERBER
LAFORIA Universite Paris 6, T 45-46 4 place Jussieu 75252 Paris Cedex 5 France Email: [email protected]
Abstract 1 Introduction
This paper describes various models of computational After having been considered as a fascinating but rather reflection in class based object oriented language. Two sophisticated feature, reflection has become an important different approaches are covered: the meta-object approach issue in the field of computing architecture and language which supposes that every object can have a meta-object design [Smith 821 Ferber 861 p.Maes 87.b] Ferber 881 describing and monitoring its behavior, and the message [Watanabe & Yonezawa 881. Reflective systems have reification approach which describes a messageas an object. shown their practical interest for implementing systems, The me&object approach is discussed more fully showing because of their ability to represent the system, i.e. its that it is important to differentiate between structural functionalities and its implementation, within the system reflection and computational reflection. We will see that, itself. Some of the key features of such systems are their whereas classes and me&asses are very important for the capacity for: former, they cannot cope adequately with the later. Therefore we introduce a model of computational reflection - implementation description: allocation of where me&objects are instances of a class META-OBJECT entities, garbage collection, incremental extension or of one of its subclasses. and re-implementation of the whole system;
Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, - monitoring entities of the language: the ACM copyright notice and the title of the publication and its date appear, inspection, analysis, and dynamic modification of and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee the code within the language itself; and/or specific permission. 0 1989 ACM 089791-333-7/89/0010/0317 $1.50
October 1-6, 1989 OOPSLA ‘89 Proceedings 317 - interfacing and debugging: implementation of 1.’ what is the nature of met&objects and/or of meta- programming tools within the language; communications, and what is their structure and behavior, - self-reorganization: learning abilities of the ii’ how is the handling of messages and lookup of system’s behavior, for an increase in consistency and methods described at the meta-level related to basic efficiency. messagepassing, iii’ when does the system uses meta-object and/or Object oriented languages (OOL) seem to be a major meta-communications. domain where reflection can easily be implemented, because of the distributed nature of data and procedure in objects. This paper introduces three models of computational However there have been just a few works on that subject, reflection in class based object oriented languages. It shows leading to two different model of reflection: that the so-called metackzsses which are very useful for structural reflection cannot deal correctly with 1 the first model advocated by P.Cointe [Cointe 883, computational reflection, i.e. they are not used at the concerns the reflective use of classes and metaclasses for computational meta level. implementing objects. In a pure class model, like OBJVLISP [Briot & Cointe 871, each entity is an instance The three models are: of a single class. Classes are instances of other classes, called metaclasses.This model allows for extension of the l the metaclass model which is based on an static part of OOL, i.e. the structural aspects of objects equivalence between the meta-object and the class of considered as implementation of abstract data types. an object.
2 the second model, introduced by P.Maes [Maes 87.a], l the specific metu-object model where meta-objects following Smiths work [Smith 821, is directed towards the are instances of a class META-OBJECT or of one of use of computational reflection within the object oriented its subclasses. programming (OOP) paradigm. This model is based on the fact that each object has its own me&object that represents l the meta-communication model which is based on all its otherwise implicit informations: its structure and its the reification of the message. way of handling messages.It has been shown that the use of meta-objects for buildind reflection in OOL allows for This paper describes the three models. All implementations the definition of new features not initially present in the are given in the OBJVLISP model of OOL. However, the system: multi-inheritance, daemons on accessof attributes, implementation is not specific and can be adapted to any interface programming, debugging tools, etc... [Maes 87.b] object oriented language using messagepassing as the basic However, this model has been defined in the context of the control structure. language KRS [Van Marcke 881, which does not support the class/instance model of traditionnal OOL such as SMALLTALK, CL0s [Michiel & Gabriel] or OBJVLISP. 2 Aspects of reflection
When defining an reflective architecture, one has to answer 2.1 Domains and reflective equations three basic questions: Creating a reflective architectures is a way of effectively i what entities should be reified, i.e. transformed into relating the implicit entities of a computation domain Dn, something which can be manipulated at the meta called the basic level, into another computation domain level? Dn+I, called the meta-level. Each domain can serve both as ii how is the causal link (i.e. the relationship between a basic domain for an upper level, or as a meta-domain for a a lower and an upper level) implemented? . . . lower level, except the domain Do, made of referents, which 111 when does the system shifts up to a meta-level? can be used only as a basic level. In the domain of object oriented languages, where the only Models of reflection can easily be defined by ways of entities are objects and messages, these questions can be reflection equations, which express how entities and reformulated as follows: expressions of the basic level, are described at the meta- level. Thus, reflective equations act as semantic equations, i.e. they give the semantics of the lower levels in terms of
318 OOPSLA ‘89 Proceedings October 1-6, 1989 upper levels. For instance, in LISP, one can give the main 2.2 Reflection in Object reflection equation for expression evaluation: oriented languages mge]pK Dn= Ml[ (eval 'e B!l[pB M [K]) 1 Dn+l In 3-KRS [Maes 87.a], when an object 0 receives a message, it delegates the message to its me&object M-O. where p and K represent respectively the environment and This process is applied again until the system finds a meta- the continuation of the evaluation of the expression e, M is object called DEFAULT-META-OBJECT,which uses a basic a semantic function from Dn to Dn+l, and where ‘e, is the interpreter of messageswritten directly in LISP. data structure that representse.
The traditional model of reflection is based on However, 3-KRS is not a class based OOL. When adapting interpretation. The domain Dn is made of a set of entities the 3-KRS style of reflection in the class/instance paradigm, and expressions, written in a language Ln, and of an one has to choose between different solutions: the meta- interpreter In which interprets those expressions. The object can be either the receiver’s class, as in the structural interpreter is written in a language Ln+l and is interpreted model of reflection advocated by P.Cointe ICointe.871, or by an In+1 interpreter. When the system is not reflective, an instance of a specific class, META-OBJECT (or an the language Ln+ I is radically different from Ln. For instance of one of its subclasses). In chapter 4 the two instance, if Ll is LISP, L2 could be a compiled language models will be presentedand discussedin details. like C or Pascal, L3 the machine language instruction set, Using a meta-object for reflection is not the only way for etc... implementing computational reflection: it is also possible In reflective architectures, there is a virtually infinite chain to reify the communication process. This leads to a of identical languages Li, the so-called reflective tower. somehow different view of reflection in OOL, which can This can be achieved because there is one interpreter, call it also be used for debugging and implementation purposes. In I’, written in a language L’ different from Li, which is used chapter 5, this model will be presented and compared to the to close the regression and replace the interpreter In at the preceding. highest level of computation needed.
For instance, in 3-LISP [DesRivikes & Smith 841 , when the system encounters a reflective function at the level Dn, 3 ObjVlisp: the demonstration it shift up one level to Dn+l . There it starts a computation. language If there is a call to a reflective function, it goes one level higher, at level Dn+2, etc... until it finds a reflective In order to develop the three basic reflection models in class function which does not use any reflective functions. All based OOL, we will use OBJVLISP, a Ianguage whose non-reflective functions are interpreted by the interpreter I’, organization is based on structural reflection [Cointe 871. written in another language. Thus reflection can be Actually this language is not important in itself and will be implemented because there is no loop in the definition of used only for demonstration purposes. Many papers have reflective function. introduced the OBJVLISP syntax. We will use this language using a blend of CLOS and Flavors syntax for readibility. P.Maes has introduced a model of reflection based on The CLOS syntax will be used for the definition of classes, representation of objects: each object 0 has a me&object and the FLAVORS syntax for the definition of methods. For M-O which represents 0 [Maes 871. This model is based on instance, the class SHIP will be described as: an intensional semantics of reference in knowledge representation, which comes from the works of L.Steels (defclass Ship (Object) (X-pos y-pos x-vel y-vel) [Steels 881: representation is a denotation process where (:metaclass Class)) concepts are implemented as conceptual objects. In this theory, every object is a representation of something, e.g. and the method DIRECTION as: an entity of the “real” world (persons, computers, files,...), (defmethod (ship direction) 0 an event, a situation, etc... computing objects can also be (atan y-vel x-vel) ) represented by other objects, the so-called meta-objects. Objects are called the referents of their meta-objects. We will suppose that, for every slots (or instance variables) there is an access method defined for it, as if the class was defined with the FLAVORSoptions :GE’lTABLE-INSTANCE- VARIABLES and :SETTABLE-INSTANCE-VARIABLES.We are interested in reflection in the messagepassing style of
October l-6, 1989 OOPSL.4 ‘89 Proceedings 319 programming, therefore we will use the standard syntax for A-l Ml (send ret se1 al an) 1 messagepassing found in LISP basedOOLl: = W[ (send (meta-of rec.)"' :handleMsg ret se1
where the DEFAULT-LOOKUP method is the basic primitive for accessing methods, and is implementation dependant. Answers to these questions will lead to two different models:
1 Use the class of the receiver as the meta-object, and go to the me&level when either the receiver or the receiver’s class wants to.
2 Use an instance of a specific class called META- However, our discussion about the different models of OBJECT and go to the meta-level whenever the reflection is not language dependant. Every OOL which has receiver has a related me&object. access to the message passing primitive (i.e. SEND) could allow for refle&on, according to the models described here. 4.1 Classes as meta-objects 4 Using meta-object for reflection In OOL based on the class/instance paradigm, the class of an object is usually considered as its meta-object, due to the As we have seen above, the first model of reflection was natural structural reflection of the model. For instance, based on the me&object approach. In this model each metaclasses are considered as meta-objects of classes object has a potential me&object associated to it which because of their ability to define the structure of classes. In describes the basic behavior (i.e. the way objects handle this model, the META-OF function is equivalent to the messages)of the related object. We say that the meta-object CLASS-OFfunction which returns the class of an object. represents the object, the latter being called the referentof the former rMaes.881. As meta-objects are objects Then the A- 1 equation above can be rewritten as follows: themselves, they can also have meta-objects or their own. A-2 N[(send ret se1 al an) 1 = Elf (send (class-of rei;" This model leads to a virtually infinite regression of meta- :handleMsg ret se1 objects, transposing the infinite tower of 3-LISP into the (list BIl[alJ . . . . g(l~anl))l realm of OOL.
According to the me&object approach of reflection, the The reflection equation says that it is equivalent, from a semantics of messagepassing can be defined by the sending behavioral point of view, for an object 0 to receive a of a specific message (called here HANDLEMSG) to the message M, or for its class to receive a message me&object: HANDLEMSG:
1 Unfortunately we cannot use the syntax of CLOS for messagesbecause of its generic function approach.
320 OOPSLA ‘89 Proceedings October l-6, 1989 M6taclass c-class (defmethod (Class Lookup) (sel) ** takes the method I ;br (send self :getmethod sel) **or try the superclass i$hen superclass (send self :lookup superclass se11 ))I HandleMsg 0 M where GETMETHOD returns the method of a given selector and is implementation dependant. One can see from the code of the HANDLEMSG method that the method is assumed to be an object, i.e. an instance of the class METHOD.
As OBJVLISP is an object oriented language embedded in LISP, applying a method consists solely in applying its associated “compiled” function to the arguments. This The HANDLEMSG method is defined in the metaclass of C definition is explicitely given in the APPLY method: (here C-Class), Thus, the default handling method is (defmethod (Method apply1 (ret args) described in the metaclass CLASS. When an object receives (apply code ret args)) a message,it has to decide if it uses the standard interpreter, or rather go to the meta-level. This can be accomplished by In OOL based on virtual machines, like SMALLTALK, the a local slot defined in the receiver or in the receiver’s class definition of the APPLY method would manipulate the (or in both). The first solution allows for the reflection of a virtual machine, i.e. create a context, set arguments on the simple object whereas the second sets all instances of a argument part of the context, sett the instruction pointer class into a reflection mode. Here is the definition of the register with the beginning of the bytecode, and jump back messagepassing primitive using the first solution: to the interpreter.
(defun send (ob j se1 . args) One should note that every modification in the . . if the receiver is in reflection mode? ;if (reflect? obj) interpretation of the meta-object implies a substitution or ;; send HandleMsg to its class an alteration of the metaclass of the receiver’s class: as (send (class-of obj) :HandleMsg messagesare sent to the class of the receiver, methods like (make-instance Message HANDLEMSG are defined in the class of the class, i.e. the :receiver obj :selector se1 metaclassof the receiver. :arguments args)) ;: here is the default interpreter ;; with built-in lookup Here are some of the consequences: (let ((m (default-lookup obj sel))) (if m (apply m (cons obj args)) - Every instances of a class share the same message (send obj :doesnotunderstand ret se1 args)))))) interpreter. There is no possibility for particularizing the interpreter of a unique object. Notice, that we use a REFLECT? function. The use of messagepassing should be avoided here because it would - Modification of the messageinterpreter can be done lead to an infinite loop. The HANDLEMSG is defined in the by substituting the metaclass: but this should be class of the receiver. In order for every object to be able to done with great care, because it can quickly lead to use reflection, the HANDLEMSG method should be defined system inconsistency. in the highest metaclass, i.e. CLASS (in OBJVLISP): - It is not possible to record personal characteristics of (defmethod (Class HandleMsg) (ret se1 args) ;; get method objects (e.g. statistical informations, history of U;tm;:;eth (send self :lookup sel)) 1 incoming messages) in the meta-objectl. This .* and apply it limitation is very crucial, because, as we will see in '\send meth :apply ret args) the following section, one of the most important . . else error (LLnd ret :DoesNotUnderStand aspect of meta-objects is their ability for storing ret se1 args))))) specific informations about their referent.
The next step is to define the methods LOOKUP and APPLY. The former is also defined in CLASS. It is a recursive 1 Except by using a dictionary where keys are instances of definition of the basic lookup procedure found in the deep the class, and values are representation of instances. But then, this is very close to the following model where meta- core of OOL (we suppose a single inheritance scheme): object are instances of the class ETA-OBJECT.
October 1-6, 1989 OOPSLA ‘89 Proceedings 321 :handleMsg ret se1 (list iE[alI . . . . iIB[anD))D Therefore, using classes as me&objects does not allow for B!JI(apply (default-lookup ret sel) the monitoring of individual objects, and metaclasses are ret (list iVl[alJ ..,. iI!I!Jan])) not “meta” in the computational sense, although they are “meta” in the structural sense. The message HANDLEMSG is sent to the receiver’s own meta-object, as shown in the following figure:
4.2 Meta-objects as instances of the class Meta-Object
This model is a variation of the “meta-object approach”, But, instead of identifying the meta-object with the receiver’s class, meta-objects are defined as instances of a class called MET&OBJECT. Those me&objects differ from the class of the receiver. They include only operational and control informations about its referent, leaving the structural informations (i.e. the description of the internal structure of the receiver) to the receiver’s class.
Then, if JOHN is an object, then (META-OF JOHN) = M- JOHN, an instance of META-OBJECT. The following figure shows the general organization of classes, instances and The main distinction between this model and the previous me&objects. one comes from the difference (in use and in implementation) of structural and computarional reflection: whereas in the former, classes are used both for structural description (definition of instance structure and of a set of applicable operations) and for computational description (how a messageis interpreted and a method is applied), this model split them apart, assigning each aspect to a different object: the class for the structural part, the me&t-object for the computational part.
This model, which is the closest to the reflection scheme of 3-KRS, shows many advantages:
- the me&object of an object can easily be modified, - an object can be monitored by its meta-object, recording what is happening and eventually deciding of changes, Each object can have its own meta-object: classes such as - it is possible to define new ways of handling PERSON,OBJECT or CLASS (me&objects of OBJECT and messagesby creating subclassesof META-OBJECT. CLASS have not been shown for clarity), meta-objects (M- JOHN can have a meta-object called M-M-JOHN), and even In order to deal with meta-objects, changes should be META-OBJECT iself. The number of meta-objects is thus accomplished in the kernel of the language. The first one virtually infinite, and it is necessary to manage the creation consists in adding a specific slot, called META, to all of me&object in a “lazy” way, meta-object being created objects. This can easily be done in modifying the definition only when needed. of OBJECT. The second one is about the definition of the primitive messagepassing function, which checks if there The reflection equation of this scheme is A-l, given above, is a meta-object bound to the receiver. It there is one, the where META-OF returns an instance of META-OBJECTor of message is delegated to the meta-object. Otherwise, the one ot its subclasses. default messageinterpretation is used: A-l BB[(send ret se1 al . . . . an)] = if (meta-of ret) (defun send (obj se1 . args) M[(send (meta-of ret) (let ((meta (meta-of obj))) ;; if there is a meta-object
322 OOPSLA‘89 Proceedings October l-6, 1989 (if meta (metaObjectClass) *- delegate the message to it (let ((m (make-instance metaObjectClass ;iend meta :HandleMsg *ref self) )) (make-instance Message (set (concat 'm- name) m) :sender self ;; makes it the meta-object :receiver obj (setf meta m) :selector se1 self)) :arguments args)) . . standard processing '(;e:lTTð (default-lookup obj sel))) Suppose that a class PERSONand two instances, JOHN and (if meth (apply meth obj args) (send obj :doesnotunderstand MARY, have been defined: se1 args)))))) (defclass Personne (object) (age) 1 In writing this function, one should take care in accessing (defmethod (Person adult?) 0 the slots META and CLASS. These should not be done by (>= age 18)) message passing for avoiding an infinite loop in the regression of reflection. Here is a possible definition of the (setq John (make-instance Personne : sex 'Male :age 35)) META-OBJECT class, whose instances can record the (setq Mary (make-instance Person number of incoming messagesof their referent, i.e. their : sex 'Female :age 24)) basic object: In a standard execution, when JOHN and MARY do not have (defclass Meta-Object (Object) any met&object, there is no shift to the me&level ((referent) .* the related object (nbMsg :initform'b));; number of messages (send John :adult?) ) ;; received by the referent = 35 and its methods: and the display of the object JOHN shows that there is no ;; the message handler which me&object associatedto it. i; interprets messages ---_---__--___--__------(defmethod (Meta-Object HandleMsg) (msq) ;;; display of : # (let* ((se1 (send msg :selector)) ------_------(args (send msg :arguments)) (ret (send :receiver))) I class : #ca class : person> (format t "Meta message: -S : -S '1 I meta : 0 ret sel) I age : 35 ;; counts the messages (setf nbMsg (l+ nbMsg)) ** takes the method It is possible to create a meta-object and to bind it to JOHN ' ilet ((meth (send self by sending the messageMAKEMETA: 'lookup iclass-of ret) sel))) ,* and apply it (send Toto :makemeta Meta-Object) iif meth (send m :apply ret arqs) The object JOHN is now monitored by its meta-object, (send ret :DoesNotUnderStand called M-JOHN, instance of META-OBJECT. For instance if se1 args) ) ) ) ) we ask if JOHN is an adult, Here the LOOKUP method is not defined in the receiver’s (==> John :adult?) class, but in the meta-object: Meta message: # : adult? = 35 ;; finding of methods in the ;; receiver's class . . and its superclasses we obtain the same result, but the system has gone up to ;defmethod (MetaObject Lookup) (obj sel) if the object is not nil the meta-level. Here is the structure of M-JOHN: (when obj ** takes the method ------i;r (send obj :qetmethod sel) I-;; display of : # . . or recurse on the superclass ------\kend self :lookup I class : # (send obj :superClass) Meta message: # : showint sell 1) ) ) 1 I ref : # I meta : 0 Here is a method, defined in OBJECT which creates and I nbmsq : 2 binds a meta-object to an object, given the class META- OBJECTor one of its subclasses: One can observe that we can obtain statistics on the
. 9 create a meta-ob ject from a SModel behavior of JOHN in M-JOHN. Notice that the number of idefmethod (object makemeta) messages is here 2, because JOHN has received two
Odober 1-6, 1989 OOP SLA ‘89 F’rocmlings 323 (send m-mary :doitagain 1) messages:the first one was about its “adulthood”, and the Re-execute # : second was sent during the display of M-JOHN (the trace of # Meta message: # : adult? the messagecan be seen in the display). = 24 It is possible to define new behavior at the meta-level by defining new subclasses of META-OBJECT. For instance, 5 Reflection as a reification we might define a class HISTORY-META-OBJECT whose of communications purpose is to record all the incoming messagesof an object in an history list : This approach is based on the reification of the communication itself: each communication can be an (defclass History-Meta-Object (Meta-Object) (history);; list of messages received object, and therefore can react to the message SEND. Thus 1) ;; by the referent the general formula for messagepassing reflection becomes:
The method HANDLEMSG has to be redefined. By using a B-l l@[(send ret se1 al . . . . an)] send super kind of message, in the “smalltalk style”. The if ret has a meta-object zz (send (make-instance Message new HANDLEMSG method becomes: :sender self :receiver ret . . refining of HandleMsg by using SEND SUPER :selector se1 idefmethod (History-Meta-Object :argu;:t;;;list INTgaIl.. BQtranD)J HandleMsg) tmsg) (setf history (cons msg history)) ;; gets the standard handler It is the responsability of the message to interpret itself. (send super :HandleMsg msg)) The class MESSAGE contains all informations needed for Then a me&object, instance of HJSTORYMETAOBJECTcan interpreting messages.The SEND method can be written: be bound to MARY: (defmethod (Message send) 0 (send Mary :makemeta History-Meta-Object) (let* ((meth (send (class-of receiver) = # :lookup selector))) (if meth (send Mary :adult?) (send meth :apply receiver arguments) Meta message: # : adult? (send receiver :DoesNotUnderStand = 24 selector self) 1))) All messagessent to the object MARY are recorded into a When a messageis sent, there is a creation of an instance of history list inside its meta-object: MESSAGE,and the messageSEND is sent to that instance:
(send m-mary :show) ------_---__--__------;;; Display of : ; ;; # ------I class :# Meta message: # : showint I referent : # I meta : 0 I nbmsg : 2 I messages : (#< a message : showint> #< a message : adult?>)
It is possible to execute a recorded message,using a method DOITAGAIN which usesthe standardHANDLEMSG method: ;; re-execute the nth most recent message ;; without memorizing it (defmethod (History-Meta-Object DoItAgain) Here, instead of being related to the receiver’s state, the (n) system shifts up for all message passing, except when it (let ((msg (nth n history))) (when msg receives a SEND message, in order to avoid loops due to (format t "Re-execute -S : -S" infinite regression. Then the system is (nearly) always in a referent msg) (send super :HandleMsg msg) ))) reflection mode.
The message ‘adult?’ can be sent again, using its index in It is easy to add new communication types by creating the history list: subclasses of the class MESSAGE, and passing them as an argument of the SEND primitive. For instance, in a
324 OOPSLA ‘89 Pmxedings October l-6, 1989 (send receiver :DoesNotUnderStand distributed system where messages are remotely sent to self))))) objects situated in different processors, there is a need for a “remote send”. This can be done by passing a specific class There is no infinite regression if we suppose that there is at REMOTEMESSAGEas an argument of the function SEND. least one meta-... meta-object which does not have a meta- Here is the definition of the SEND primitive in this model: object.
(defun send (obj &keys selector arguments messageclass) (if (eq selector 'send) 6 Conclusion ;;; standard processing (let ((meth (default-lookup obj sel))) (if meth (apply meth obj args) We have covered several models of computational reflection ss else go to meta ibend (make-instance for object oriented languages with classes, and have (or messageclass Message) discussed the consequencesof thesesmodels. We have seen :sender self that metaclassesare not a good candidate as me&objects for :receiver obj :selector selector computational reflection. Then it is important to :arguments arguments) distinguish between structural reflection, where metaclasses :send))) are very helpful, and computational reflection, where a specific class, called META-OBJECT, should be introduced Then, sending a remote messageADULT? to an object JOHN as the root class of all meta-objects. can be done as follows: Messages also can be reified by allowing them to be (send John :selector :adult? :messageClass RemoteMessage) instances of a class MESSAGES.In SMALLTALK, the class MESSAGEis only used for debugging purposes, whereas we Compared to the preceding models, this one has the have used them for all messagepassing. There is only one following advantages: message which should not go to meta: the SEND message sent to an instance of the class MESSAGE. - It is easy to differentiate between several types of messages: subclasses of communication can be Then we have seen that reflection by meta-objects, and defined and used instead of the standard MESSAGE reflection by messagereification can be used altogether. class.
- The use of different types of messages allows an incremental extensions of the possible use of the 7 Aknowledgment system. Addition of notion such as concurrent message passing, continuation, etc... can easily be I would express my gratitude to J.P.Briot, whose critical incorporated. comments about the necessity to clarify many of the ideas However, the main disadvantage of this model is that it discussed here have been the starting point of that paper. I does not say anything on objects: it is impossible to also benefitted from the encouragements and discussions of monitor objects, to represent specific informations about P.Cointe and J.F Perrot. receivers, or to represent the behavior of a single object. It should be noted that this model can be used in conjunction with the “met&object” models. For instance, here is a References modified version of the SEND method defined in the class [Agha 861 G. Agha, “Actors - A Model of Concurrent MESSAGE which permits the use of meta-objects as Computation for Distributed Systems,” MIT Press, 1986. instances of the class META-OBJECT (or one of its subclasses): [Briot & Cointe 871 J-P. Briot and P. Cointe, “A Uniform (defmethod (Message send) () Model for Object-Oriented Languages Using the Class ;; if there is a meta-object Abstraction,” IJCAI’87, Milano, Italy, August 1987. (if (meta-of receiver) :: delegate the message to it (send (meta-of receiver) [Cointe.87] P. Cointe “Me&lasses are first class objects: :HandleMsg self) (let* ((meth (send (class-of receiver) the OBJVLISP model”, OOPSLA’87 Orlando, USA, :lookup selector))) October 87. (if meth (send meth :apply receiver arguments)
October l-6, 1989 OOPSLA ‘89 Proceedings 325 [Cointe 881 P. Cointe “A Tutorial Introduction to [Smith 821 B.C. Smith, “Reflection and Semantics in a Metaclass Architecture as provided by Class Oriented Prdurd Language,” PhD Thesis, TR 272, M.I.T., USA, Languages”, Fifth Generation Computer Systems 88, 1982. Tokyo, Japan, November 1988. [Van Marka gg] K. Van Marke, “the Use and [De&vi&es 8~ Smith 841 J.C. DesRivieres, B.C. Smith, Implementation of the Representation Language KRS” PhD “The Implementation of Procedurally Reflective thesis, Vrije Universiteit Brussel, April 8% Languages”, ACM conference of the third ACM Lisp and Functional Programming, Austin, USA, July 1984. Dyatanabc C Yowzawa tl] T, Watanabeand A. Yonezawa, “Reflection in an Object-Ortid Concurrent Language,” [DAI $71 “Distributed Artificial Intelligence,” edited by M. OOPSLA%3 draft, ‘ITT, Tokyo, Japan, April 1988. N. Huhns, Pitman - Morgan Kaufman, 1987.
[Ferber 841 J. Ferber, “Mering: An Open-Ended object oriated &tguage for knowledge representation” ECAI’84, Italy, September 1984.
[Ferber 863 J.Ferber, “Towards a Reflective Actor Language”, ECAI 86, Brighton, Great Britain, July 1986.
[Ferber 881 J. Ferber, “Conceptual Reflection and Actor Languages,” in [Reflection 881.
[Ferber & Briot 883 J.Ferber & J.P. Briot “Design of a Concurrent Language for Distributed Artificial Intelligence” Fifth Generation Computer Systems 88, Tokyo, Japan, November 1988.
[Maes 87.a] P. Maes, “Concepts and Experiments in Computational Reflection,” OOPSLA’87, Sigplan Notices, Vol. 22 N’12, December 1987.
[b&s 87.b] P.Maes “Computational Reflection” PhD thesis. Vrije Universiteit Brussel, 1987, also Technical Report 87-2.
[Maes 881 P. Maes, “Issues in Computational Reflection,” in [Reflection 881.
[OOCP 871 “Object Oriented Concurrent Programming,” edited by A. Yonezawa and M. Tokoro, MIT Press, 1987.
[Pitrat 851 J.Pitrat “Maciste ou comment utiliser un ordinateur sans &ire de programme. Colloque Intelligence Artificielle de Toulouse, Research Report LAFORIA n”58, 19815.
[Reflection 881 “Me&Level Architectures and Reflection,” edited by P. Maes and D. Nardi, North Holland, 1988.
[Steels 881 L.Steels “Meaning in knowledge representation” in [Reflection 881.
326 OOPSLA ‘89 Promdngs October 1-6, 1989