Towards a Methodology for Explicit Composition of MetaObjects

Transcription

1 See discussions, stats, and author profiles for this publication at: Towards a Methodology for Explicit Composition of MetaObjects Article December 1999 Source: CiteSeer CITATIONS 2 READS 29 4 authors, including: Jacques Malenfant Pierre and Marie Curie University - Paris 6 93 PUBLICATIONS 710 CITATIONS SEE PROFILE Pierre Cointe IMT Atlantique 93 PUBLICATIONS 932 CITATIONS SEE PROFILE All content following this page was uploaded by Jacques Malenfant on 28 November The user has requested enhancement of the downloaded file.

2 Towards a Methodology for Explicit Composition of MetaObjects Philippe Mulet, Jacques Malenfant, Pierre Cointe Ecole des Mines de Nantes & OTI Laboratoire Jules Verne La Chantrerie - 4, rue Alfred Kastler Nantes Cedex 03, France [mulet,cointe]@info.emn.fr Departement d'informatique et de Recherche Operationnelle Universite de Montreal. C.P Succursale Centre-Ville Montreal, Quebec, Canada H3C 3J7 malenfan@iro.umontreal.ca Abstract Reective programming languages are those where users' programs are allowed to customize in an organized way the behavior of the language to their own needs. For ten years now, most of the work on reection revolved around the denition and the implementation of metaobject protocols which express this organization. No methodologies have been proposed for reective programming per se. This paper proposes a rst one aiming at the design of composable metaobjects. Given two independently developed reective customizations, this methodology proposes principles to be observed in their design such that they can be composed using standard base-level aggregation or specialization. While this paper focuses on a simple MOP and illustrates the methodology on specic examples, this methodology can be generalized to other languages with dierent MOPs. For instance, we discuss how to adapt it to Clos. Keywords Composition, Aggregation, Specialization, Reection, MetaObject Protocol, Methodology, Incrementality. Introduction Reection in programming languages, which dates back to the seminal work of Smith in the early eighties [23], has been dened as \the ability of a program to manipulate as data something representing the state of the program during its own execution" [4]. The goal of reection is to allow users' programs to reason about their own execution state and eventually alter it to change their own meaning. Several object-oriented reective languages have been proposed [6, 7, 15, 17, 19, 22, 24]. In fact, during the last ten years, the research has been focused on proposing new metaobject protocols (hereafter MOP), the quintessence of which being the Clos MOP [15], and on implementing them. In OOP, a MOP denes the set of metaobjects as well as the interactions between them (communication protocols) representing the way programs are executed in that language. Users' programs may customize their behavior by specializing standard metaobjects. Frequently cited specializations range from tracing and debugging to changes in the representation of objects as well as new semantics for inheritance (in class-based languages). Besides the eort put on their denition, little experience has been gained in using such MOPs intensively. The central problem we attack in the present paper is the reuse of already existing cus-

3 tomizations, which can be rephrased in the following question: \Given two customized behaviors A and B, implemented as metaobjects M A and M B, that I would like to use at the same time in my program, is it possible to compose M A and M B into one combined customization M AB?" Moreover, since we would like to use M A and M B as black boxes, what are the least conditions we have to impose on them in order for this composition to work properly? And nally, since reection has the major outcome to unify both the base and the metalevels within the same programming paradigm, we want our composition mechanism to take advantage of the two traditional ways to compose behaviors in OOP, namely aggregation and specialization. This kind of issues are crucial to the widespread use of reection. Because implementing customizations can be rather involving, and because metalevel programming is acknowledged as a dicult and potentially dangerous task (because of its system-wide implications), reusing existing customizations is particularly interesting. A composition mechanism like the one we look for has the potential to drastically augment the power of re- ection by making the creation of combined customizations within the reach of everyday programming. As we will point out in the paper, composition in its full generality is a very hard problem because of the interferences that may appear between the combined customizations. Therefore, we begin our study with a simple MOP in order to propose a rst methodology for the design of composable customizations. This methodology is organized around a limited number of design principles and composition mechanisms. Our experiments are conducted using as testbed our prototype-based reective language, called Moostrap, whose MOP decomposes message execution according to the equation lookup apply, where message sending is viewed as the composition (from left to right) of the operations lookup and apply [18]. In our language, lookup and apply operations are represented as methods that can be specialized as any other methods in the system. Each object has a metaobject whose duty is to answer lookup messages, therefore dening the way their mandator object 1 reacts to a message. The rest of the paper is organized as follows. In Section 1, we describe the problem of composition and highlights the diculty of composition in its full generality. In Section 2, we introduce our methodology for making use of composition. Then in Section 3, we illustrate the methodology in our testbed on a practical example. In Section 4, we investigate the generalization of this methodology in the context of Clos MOP. Finally, we review related work and conclude on future work. 1 Composing Semantics Composing semantics is a general problem, that can be handled for metaobjects inducing some constraints leading to a specic methodology. 1.1 A General Problem Composition is encountered in many dierent domains, let us review and take advantage of some of them. Composing functions Functional programming borrows from mathematical functions the natural idea of their composition. Moreover, since functional languages emphasize functions as rst-class entities, function composition can be implemented within the language as a second order operation. For example, composing functions f and g in Scheme can be achieved by the denition of a compose operator 2 linking them up as follows: (define (compose f g) (lambda (x) (g (f x)))) This semantics of composition makes no assumption on the respective functions bodies, however connecting their input/output imposes constraints 1 The base-level object regarded as referent of a given metaobject that describes its computational semantics [17]. 2 For instance, sequencing the two functions according to the European interpretation of fg.

4 basic-meta-object lookup in the only receiver. counting-meta-object counts the number of messages handled daemon-meta-object associate daemon actions to methods delegating-meta-object implements algorithms of delegation tracing-meta-object display a tracing message constraint-meta-object handle constraints between objects delegating-meta-object implements algorithms of delegation tracing-meta-object display a tracing message link to the metaobject is composed with link to the delegatee tracing-meta-object display a tracing message Left-Composed Metaobjects delegating-meta-object implements algorithms of delegation Right-Composed Metaobjects Figure 1: Deriving complex metaobjects by composing elementary ones, the composition link is oriented introducing notions of left-composed and right-composed metaobject. on the number and the types of the arguments. Indeed, f and g should be unary, and respect the following type signature of compose: compose: (! ) (! )! (! ) Subclassing Inheritance combines a parent P and a modier M into a result R = compose(p,m): : : [25] Inheritance is an incremental modication mechanism imposing constraints on the design of the subclass, for structural and behavioral compatibility, since the subclass is dened by extension of the superclass. Combining methods Before/after methods of Clos [9] or Flavors [20] allow programmers to activate more than one method in response to one message. However, the constraint of unicity of the returned value cannot by bypassed and the before/after methods can only perform side-eects. These languages enable the user to specify manually alternative combination operations for around methods. In the same way, inheritance allows to override methods, while some facilities are provided to invoke overridden methods, requiring an explicit invocation either from within the specializing method (super in Smalltalk, call-next-method in Clos, resend in Self) or from the specialized method (inner in Beta). In fact, there is no general composition mechanism, but rather particular solutions, imposing specic constraints. According to this point of view, we propose a model of composition for metaobjects, study its inherent constraints and elaborate a methodology for using it. 1.2 Composing Metaobjects Since a MOP reies 3 computational semantics as metaobjects, it supports the denition of new semantics through the addition of new metaobjects, such as for metrics, daemon actions, particular forms of delegation, traces or handling constraints at the metalevel. Practically, MOPs usually oer customizable functionalities, as a set of elementary bricks, which only have to be assembled together so as to de- ne the complete semantics of the system, since there is no overlap between their respective implementations. CodA [19] illustrates this approach by providing an initial set composed of seven such orthogonal functionalities, and advocates to build complex semantics by combining customized but 3 To reify: \to make thing", i.e. to have something initially hidden become a rst-class entity of the language.

5 still orthogonal functionalities. Conceiving such functionalities requires to know precisely the roles and implementations of all the components in the MOP so as not to introduce any overlapping additional functionality. Then, assembling pure orthogonal functionalities restrain drastically the range of possible combinations, since several customizations of the same brick cannot be composed, unless an expert designer manually solve conicts between overlapping semantics. The issue we intend to deal with here is precisely the composition of non-orthogonal semantics. We advocate the realization of elementary metaobjects (only one customization per metaobject), having potentially overlapping semantics, and we target to reuse them afterwards by automatic composition (cf. Figure 1). However, as we want to preserve the encapsulation of metaobjects, we cannot interlace their respective algorithms. Furthermore, in the context of reective programming, we do not presuppose any additional facility for composing objects other than the standard base-level mechanisms, such as specialization and aggregation. Thus we envisage metaobjects composition as a special case of composition of objects (i.e. composing metaobjects only means composing objects that have metalevel properties), and we associate metaobjects in pairs, in an oriented relation, by having one of them specializing or aggregating the other (cf. Figure 2). Let us call the former the left-composed metaobject and the latter the rightcomposed metaobject. Composing metaobjects only means having the left-composed one requesting explicitly the functionalities of the right-composed one, without knowing the internal implementation of the latter. The resulting cooperation depends closely from the nature of the composition link. aggregating-meta-object Specialization: the left-composed metaobject specializes the other metaobject, either by inheritance or delegation. Thus, it inherits all functionality from its parent, and can rene it if necessary by accessing the overrid- recall the composed algorithms by message sending embedded specializes value link meta-link specialized-meta-object composed-meta-object composed semantics specializes the composed algorithms and may refine them. Figure 2: Applying the base-level mechanisms of composition to metalevel programming. den properties. The communication is bidirectional: from the left-composed to the rightcomposed by inheriting/accessing overridden properties, and from the right-composed to the left-composed when the former sends messages to self. Aggregation: the left-composed metaobject embeds the other one as a part of itself, and explicitly activates the composed properties when necessary, by sending messages to the composed part. As a result, the communication between the metaobjects is unidirectional from the left-composed to the rightcomposed, because the self reference to the left-composed metaobject is lost when activating the right-composed one. However, since aggregation or specialization are not expected to compose metaobjects, we have to design metaobjects so as to explicitly cooperate along the composition link. 1.3 Impact on Metaobject Design Each composition solution induces particular constraints on the internal design of the metaobjects making use of it. Cooperative metaobject According to this model of composition, a leftcomposable metaobject must anticipate requesting the cooperation of the future right-composed, by sending explicit messages to it. Hereafter, such a

6 apen basic-meta-object default semantics apen x 1 y 2 basic-meta-object default semantics value link meta-link tracing-meta-object verbosely recall the composed algorithms by message sending embedded aturtle parent head 90 specializes value link meta-link delegating-meta-object refine the inherited semantics so as to implement a delegation using the link stored in the mandator object Figure 3: Trace and delegation implemented as left-composable semantics, the respective metaobjects cooperate initially with a default semantics, implemented by a basic metaobject. left-composable metaobject will be qualied as cooperative. A cooperative metaobject can be considered as a metaobject containing a \hole", into which will be inserted afterwards another metaobject. And, as long as it is not composed, a cooperative metaobject may be not consistent enough to be used autonomously. Indeed, it describes only a partial semantics: an extension to the semantics of its future component, which is not yet speci- ed. Notice, that default semantics of reective systems are usually reied through basic metaobjects (i.e. build-in metaobjects). In our study, such metaobjects are not expected to be cooperative, but they can be used to ll the \holes" of cooperative metaobjects, and have them become concrete. Communication between objects and their respective metaobjects can raise severe compatibility issues, since the metalink extends in a new direction the categories of collisions between objects identied in [3]. Inter-level communication Initially, metaobjects are only assumed to handle the unique contract enforced by the MOP. However, locally, the user can intentionally extend the behavior of a metaobject to solve a given problem. For example, counting invocations of generic functions in Clos [15, p.109] is achieved by specifying a new metaobject for generic functions (counting-gf), which enlarges the initial MOP with the call-count functionality enabling to consult the number of invocations for a counting method. Then if the two composed metaobjects implement such locally enhanced protocols whose methods are called by the base-level objects, then their combination can run into severe interference between the two components. In particular, name clashes can happen between dierent behaviors implemented under the same protocols (names) in the two components while if the same behavior is implemented using dierent protocols, some \glue" may be needed to make them work together. Global extensions to the MOP are less harmful. Because they are properties applicable to all the metaobjects in the system, we can cope with them uniformly in the composition mechanism. In this paper, we assume that all message passing between objects and their metalevel sticks strictly to the initial MOP's contract. We defer to future work the relaxation of this assumption and how to cope with global extensions to the MOP as well as local protocols between an object and its metaobject. Intra-level communication Besides message passing between objects and metaobjects, message passing between metaobjects themselves can raise compatibility issues. A good way of constraining the communication between metaobjects is to consider any cooperative metaobject as initially composed with a basic metaobject. A rst consequence is that the cooperative

7 metaobject can be used by itself, as shown in the right part of Figure 3. In this example, the delegation link is a standard property of aturtle dynamically interpreted by its metaobject (see Section 3.2 for implementation details). When composed, the internal reference to the basic metaobject (previously the \hole" in the cooperative metaobject) is replaced by that of the component metaobject. As a second consequence, the implementation of a cooperative metaobject cannot make any assumption upon the contract provided by the future component metaobject because, as a working metaobject by itself, it must already restricts messages to its component metaobject to the minimal contract dened by the basic metaobject. Composing twice cooperative metaobjects If we stick with the two composition mechanisms proposed in the previous subsection, once composed, a cooperative metaobject is no longer leftcomposable by itself without losing its current component. Thus, the only way to compose it again consists in using it as the right parameter of a further left-composition (e.g. using the example shown on the left part of Figure 3, tracing-meta- -object could be itself embedded inside an another cooperative metaobject). Hence, in general, we could only extend metaobjects to the left with elementary customizations. In order to relax this constraint, we must extend our aggregation and specialization mechanisms with a more general composition mechanism coping with already left-composed metaobjects. Unfortunately, this approach will force us to extend the MOP in order to include composition, as we will see in Section 2.2 where we discuss the implementation of this extended scheme. Design rules for cooperative metaobjects Henceforth, we want to compose non-orthogonal metaobjects, but restricting their overlap to the only properties specied in the MOP, on which we can make assumptions. Thus an explicit model of composition requiring the cooperation of metaobjects can be described, providing that their individual designs respect the following rules. Exclusivity: When a meta-operation is performed on any object, its respective metaobject must be activated to this aim, since it is assumed to be the only one capable of performing this task. Encapsulation: A metaobject is a black box whose external interface corresponds exactly to the protocol specied by the MOP. Independence: The implementation of a given metaobject must make no specic assumption on the base objects implementation (especially structural assumptions), and rather encapsulates all the information related to its specic concerns. 2 Making Use of Composition Composing metaobjects is not a global operation, it is a problem solved locally by each cooperative metaobject. Therefore, we have to propose a methodology for making use of metaobject composition, depending on the degree of awareness in MOP of the user. 2.1 The User Point of View End-users don't want to see the implementation details of the metalevels, in particular the composition aspects. The enhanced behaviors should be easily activable, thanks to a library of functionalities provided by a relevant metaobject designer, and available as global operations. These high-level operations encapsulate all the metalevel ones, especially composition semantics which may be involved implicitly. For instance, an end-user would only use active-trace/unactive-trace or build-delegation-between/remove-delegation as highlevel operation, for activating/unactivating traces or delegations. Then, he can perform incremental customizations of behavior without being aware of them, requiring implicit handling of composition, as illustrated by the following stereotypical situation and Figure 4 :

8 apen basic-meta-object x 1 default semantics y 2 aturtle parent head 90 delegating-meta-object refine the inherited semantics so as to implement a delegation using the link stored in the mandator object link to the metaobject is composed with link to the delegatee tracing-meta-object verbosely recall the composed algorithms by message sending Figure 4: Composition of metaobjects used for incrementally enhancing the semantics of a mandator object, a trace is activated in addition to a previous delegation, without even being aware of its pre-existence. The designer Joe is implementing a turtle object for the user Bob. He creates two prototypes: aturtle and apen. He adds a delegation link from aturtle to apen, handled implicitly by a suitable metaobject 4. He goes back home. The user Bob only knows that he can use the prototype aturtle, and that maybe its metaobject is important. He wants to trace the messages sent to it, and therefore uses the facility active-trace on aturtle. This incremental enhancement requires the composition of the tracing behavior with the previous delegation, and in this particular case, without being aware of the pre-existence of delegation (automatic composition). 2.2 The Designer Point of View Let us focus on the implementation of the above user-facilities encapsulating composition. The metaobject designer rst designs cooperative metaobjects, according to the rules enounced in Section 1.3, and implements some composition operations, respectively by aggregation or by specialization as follows (the location of such generic operations is discussed below): 4 He could use his high-level operation build-delegation. compose-by-aggregation (coop-mo any-mo) value with any-mo the slot \embedded" of coop-mo. return coop-mo compose-by-specialization (coop-mo any-mo) position the specialization link from coop-mo to any-mo. return coop-mo Composition is solved locally for each metaobject, and thus its designer either choose aggregation or specialization. The next question coming to mind is how to organize these composition operations? The two possible solutions are either to merge them directly in the user-facilities such as the trace facility mentioned before (local to functionalities), or to implement them as methods in the metaobjects themselves (local to metaobjects). Previously, in Section 1.3, we said that compatibility issues could be avoided by preventing the initial MOP from being extended, especially locally. In particular, composition aspects should respect this rule, and consequently composition operations have to be interlaced in the internal code of the user-facilities, melting base-level intervention with metalevel composition. For instance, the addition of a delegation link realized by build- -delegation-link requires the addition of a link into the mandator object (designating the delegate), and the use of a special metaobject (dynamically interpreting this link) composing the preexisting behavior of the mandator object.

9 The second solution extends the MOP, so as to consider that cooperative metaobjects can respond to a message compose-with, and thus putting a barrier of abstraction around metaobject composition. Consider for a moment that any cooperative metaobject knows how to compose itself with another one, depending on how it envisages the explicit cooperation (aggregation or specialization). According to this latter approach, the composition could enlarge deeply the population of cooperative metaobjects. In fact, a cooperative metaobject only has to provide a \hole" where we can insert a right-composed metaobject. But in fact, when the right-composed metaobject is itself cooperative, it remains a hole inside the latter that could be used afterwards, for a new composition in depth. Figure 4 illustrates this point: the already composed delegating-meta- -object could be left-composed to another complex metaobject, instead of just reusing a basic metaobject. Consequently, we would not be forced to left-compose elementary behaviors, and thus tracingdelegatingbasic-meta-object could be left-composed with any other metaobject any-mo, to become tracingdelegatingany-mo. This extension could be handled in a transparent way, by dening the compose-with functionality for any cooperative metaobject as follows: 1 compose-with (any-mo) 2 if the receiver's metaobject is still elementary 3 then use one of the two previous operations of 4 composition 5 else replace the previous right-composed 6 metaobject by the result of its recursive 7 composition with any-mo When requested to compose with any-mo, a cooperative metaobject checks whether it is already composed or not (line 2). If it is still elementary (line 2), it can left-compose as described previously (lines 3 and 4). And if already composed with a cooperative metaobject, it updates the reference on this latter metaobject with the result of its own composition with any-mo (lines 5 to 7), allowing the process to be extended to the next levels in depth recursively. The next step would be to extend the MOP globally, and now consider that any metaobject in the language could be asked to compose-with another one. It removes thus the assumption of leftcomposability upon the right-composed metaobject. In particular, basic metaobjects could consider themselves as neutral elements of the composition, thus simply returning the component-mo when requested to compose with it. Hereafter, we restrain the communication between metaobjects to the initial MOP contract, in particular, we neither include the compose-with operation as a primitive nor as an enhanced MOP functionality. 3 Implementing Composition We now describe the application of this model to the language Moostrap, illustrating composition with trace and delegation. 3.1 A MetaObject Protocol Moostrap is an implementation of the MOP lookupapply in a minimal prototype-based language. This MOP formally established in [18] assumes that any object is described by a behavioral metaobject, which handles the lookup phase, and that the result of the lookup must know how to apply itself. Hence, any message sending (receiver selector arg 1 : : : arg n ) is decomposed as follows (denoting by meta-object the metaobject of the receiver): Request the metaobject to perform a lookup in the receiver : (meta-object lookup receiver selector) Request the application of lookup-result: (lookup-result apply receiver #(arg 1 : : : arg n )) In Moostrap, the sole contract enforced by the MOP is that a metaobject is simply an object that can handle the message lookup. The link from an

10 basic-meta-object lookup meta link message sending apoint x 1 y 2 display display handled as apoint x y display 1 2 basic-meta-object lookup lookup apoint "display" apply apoint () Figure 5: Reication of message passing: the message display sent to apoint is split up into two new messages: lookup sent to the basic-meta-object and apply sent to the result of the lookup (symbolized by the \lasso"). object to its metaobject can be dynamically consulted or modied. Initially, the system proposes only a rst metaobject 5, called basic-meta-object, which implements a rst algorithm for slot lookup (the basic lookup 6 ), searching for the slot only in the receiver of the message. Further details about the implementation of Moostrap can be found in [21, 22]. New semantics of message passing can be introduced by extending the library of metaobjects. Let us instantiate the generic rules expressed in Section 1.3 for the lookup operation, on which we will focus our study. Exclusivity: A lookup phase must not be performed in an object without invoking the algorithm of its metaobject. Encapsulation: A metaobject is a black box, and its external interface is only assumed to accept lookup messages. Independence: In a given metaobject, the lookup algorithm must be independent of the object implementation. 5 This basic metaobject is self-described, introducing a circularity in the metalink a la ObjVlisp [7]. 6 In this case, the term \lookup" may be misused since there is no search outside the receiver. 3.2 Composing Trace and Delegation We now show how to design some cooperative metaobjects in Moostrap. Trace Tracing messages sent to a given object can be handled as a verbose algorithm for message lookup and implemented as follows by a new metaobject (tracing-meta-object): lookup (receiver selector) display the suitable information. recall the embedded lookup The left part of Figure 6 illustrates trace on an object apen which is associated to this new metaobject, tracing-meta-object does not require the tracing semantics for itself, so it uses basic-meta-object. Delegation In Moostrap, delegation is already a variation upon the basic lookup semantics, validating the extensibility of the MOP. It extends the process of search, without changing the initial receiver onto which the matching slot will be applied nally. We only consider here a single semantics of delegation, where an object designates exactly one delegate, through an explicit reference (a slot). This initial semantics could be enriched afterwards. Therefore, we introduce a

11 apen x x: y y: draw 10 <- 50 <- meta link value link basic-meta-object lookup basic lookup tracingobasic-meta-object lookup verbose lookup embedded apen x x: y y: draw aturtle parent heading draw 10 <- 50 <- 90 basic-meta-object lookup basic lookup delegatingobasic-meta-object lookup delegatingoembedded lookup embedded meta link value link Figure 6: Examples of lookup customizations: trace and delegation as cooperative metaobjects. new metaobject (delegating-meta-object), implementing such an algorithm of lookup. Preventing from further metaobject compatibility issues, we must take care of the fact that a lookup phase must not be performed in an object without invoking its metaobject. Thus, we implement delegation as a succession of local redirections from each object to its parent, using the associated semantics of lookup implemented by each respective metaobject: lookup (receiver selector) recall the embedded lookup. if the local search failed then request the metaobject of the parent to propagate the lookup to the delegate else return the matching slot endif A delegation link is specied by adding an explicit reference to the delegate (slot parent) in the delegating object, and replacing its metaobject by delegating-meta-object (cf. Figure 6, right part). Composing Bob can now trace the object aturtle, by incrementally composing its trace-meta-object with the preexisting metaobject provided by the implementation of Joe (cf. Section 2.1) as illustrated by Figure Composing two Delegations A semantics of multiple delegation could be implemented as a composition of several single delegations. The order of composition induces a priority between the delegates: the last added delegation is performed last. However, when adding a delegation link to a given object which is already delegating, the new link to the delegate, parent, may overload the previous one. Of course, one solution would be to use dierent names for the references to the delegates, but this is not satisfactory because it requires to unveil the implementation of the former metaobject when extending it by composition. In fact, delegation is a metalevel customization; why isn't it fully handled at the metalevel? The conict comes from the structural dependence between the metaobject and the mandator object. We must remove this structural assumption: the link to the delegate has to be stored in the metaobject itself. Now, the interface of the concerned objects is no longer altered when introducing a delegation relation. Indeed, aturtle may be implemented by delegating to apoint (cf. Figure 6), but is this a reason to have the parent slot be accessible in its interface? This implementation considers that the delegation is rather an implementation detail, managed at, and only at, the metalevel. Separation of concerns [12] induced by MOPs

12 apen x x: y y: <- draw aturtle parent heading 10 < draw meta link value link basic-meta-object lookup basic lookup delegatingobasic-meta-object lookup delegatingoembedded lookup embedded tracingodelegatingobasic-meta-object lookup tracingoembedded lookup embedded Figure 7: Example of composition of a trace with a delegation: aturtle was delegating to apen, and then incrementally its behavior is enhanced so as to trace the messages it receives. The former semantics is embedded into the latter. breaks the whole semantics into elementary components, each specialized in its relevant domain. The full respect of design rules for cooperative metaobjects emphasizes the separation of concerns between metalevels. It increases the dependence from base-level objects to their metalevels, for understanding the global behavior of the system. Indeed, base-level objects only contain the emerged part of the \semantical iceberg", the submerged part corresponds to metalevels. This latter behavior is harder to understand for an end-user, but user-friendly tools must be provided so as to help him seizing the system (in the same way as Smalltalk browsers help to navigate along the inheritance link). 4 Generalization In this section, we investigate the generalization of our methodology of composition. We focus on Clos MOP [14], since it is currently considered as the quintessence of MOPs, and we will show how to introduce explicit metaobject composition, and especially how to exploit its characteristics. Clos features the rst mechanism for specialization dened by Flavors: a semantics of multiple inheritance based on the linearization of the ancestor graph, building accordingly a precedence list of ancestors for each class. For us, moving to Clos MOP naturally introduces a new mechanism of composition for metaobjects based on this linearized multiple inheritance graph. In Clos MOP, metaobjects represent one program element, and are instantiated either from one of the ve basic metaobject classes (class, slot- -definition, generic-function, method and method-combination), or from some of their respective subclasses. Designing metaobjects for linearization In our model, a cooperative metaobject must foresee its future composition, and, to this aim, its properties encapsulate explicit requests to its future component. Previously, we saw that this explicit communication must strictly stick to the only MOP contract. Practically, Flavors inheritance already advocated the conception of cooperative components. Indeed, linearization allows to compose, in an precedence list, some abstract components describing generic but partial behaviors, also called mixins.

13 \A mixin avor is a avor that denes one particular feature of an object. A mixin cannot be instantiated because it is not a complete description. Each module or feature of a program is dened as a separate mixin: a usable avor can be constructed by choosing the mixins for the desired characteristics, and combining them, along with the appropriate base avors." [26] Conceiving mixins requires not to interfere with other behavior, which either means to implement orthogonal behaviors thanks to before/after methods [13, p.228], or to anticipate their future composition, i.e. their methods explicitly perform call- -next-method invocations 7 so as to request the cooperation of the other components involved in the precedence list. Since mixins are the basis for a compositional inheritance mechanism [5], cooperative metaobjects can be regarded as a subset of mixins which implement MOP functionalities. We can envisage to describe as concrete components, the basic metaobjects of Clos MOP, and then derive new ones as elementary mixins, following the Flavors recommendations. \The facility might provide a base avor and a set of mixins, and the caller can combine these in various combinations depending on exactly what it wants, since the facility probably would not provide all possible useful combinations." [26] Composition is achieved when dening a concrete complex metaobject, incorporating several semantics supported by as many mixin-metaobjects, and a nal one which is the respective basic metaobject. The linearization will realize composition, and call-next-method will activate dynamic cooperation of metaobjects. Notice that such mixin metaobjects are only assumed to handle MOP facilities, thus restraining their communications to a nite set of messages, enabling them to be composed blindly. list. 7 Access the next overridden method in the precedence Incremental composition Though the order of composition closely depends on the process of linearization, incremental composition can still be achieved, it consists in building a new metaobject and inserting in rst position of its ancestors, the mixin corresponding to the added functionalities. Thus, our methodology for making use of metaobject composition is fully applicable. In conclusion, metaobject composition in Clos can be viewed as a particular case of mixin-based composition, provided that our rules of design for cooperative metaobjects are respected. 5 Related Work Composition-lters The composition-lters approach [1] is a rare example of a system allowing composition of customized semantics. Composition-lter objects encapsulate properties, the activation of which is controlled by lters that intercept the incoming and outgoing messages. Filters are described within the language itself (metaobjects), allowing the denition of various enhanced semantics for message passing. The system also supports the composition of several lters, providing thus a mechanism for metaobject composition. In fact, the composition is implicitly handled by sequencing the activation of the respective lters, connecting them by a logic and operator. In our model however, the metaobjects themselves dene the composition semantics, which is thus reied and can be expressed in dierent ways. Metaobjects really cooperate together by joining their respective capabilities to achieve message passing. Thus a left-composed metaobject can translate the message for its right-composed part, or reformulate its response (encapsulating it with additional behavior), the activation of the rightcomposed metaobject can be requested during the activity of the left-composed one rather than consecutively. Moreover, we allow several dierent composition semantics to coexist simultaneously, and support the denition of new semantics of composition.

14 Metaclass Composition Apart from composition-lters, composition of customized semantics has been a neglected subject in the reection community. In most systems, it is left to the responsibility of the user who must implement explicitly the combined customization, often resulting in involving multiple inheritance. While compatibility problems have been pointed out in the context of metaclasses [10], no composition mechanism has been proposed to solve the problem yet. In a recent paper [8], a partial solution has been proposed in SOM, but it unfortunately involves the creation of implicit metaclasses, defeating in a sense the purpose of a system that advocates the use of explicit metaclasses. Furthermore, little is said about potential interferences between the two supposedly \composed" metaclasses, while this is the crucial point of our methodology. Practically, a derived metaclass is associated to a mandator class when a compatibility issue is statically suspected. This metaclass gathers, by linearized multiple inheritance, all the functionalities provided by the respective metaclasses of the mandator class' superclasses. As a result, the mandator class automatically benets from all the class properties of its superclasses, potentially inducing coherency issues, since some of the properties, such as abstractness 8, should not be inherited. Enhanced Mechanisms of Composition Since we consider the composition of metaobjects from the point of view of object composition rst, other enhanced mechanisms for explicitly describing the cooperation of objects, such as propagation patterns [16], contracts [11], role models [2], equally provide many interesting directions for the composition of metaobjects. However, since we are in a reective context, we must formalize these additional specications in term of new metaobjects dedicated to this purpose. 8 Practically, in SOM abstractness is not implemented as an inheritable class property, but rather by an additional variable introduced on each class so as to toggle it manually either as concrete or abstract Conclusion Regarding metaobject composition as a particular case of object composition, we have proposed a rst methodology for the design of composable reective customizations in the context of our prototype-base reective language based on the lookup apply decomposition. Our composition model is based on explicit cooperation between metaobjects, and to this aim their implementation must respect three design rules, in order for them to cooperate properly together once composed. In particular, we have seen that these rules emphasize separation of concerns, so that mandator objects only correspond to the emerged part of the \semantical iceberg", and their full semantics are thus dicult to seize. This last point highlights the need for enhanced introspective tools, and practically MOPs should typically integrate facilities so as to describe themselves user-friendly for end-users. Although our composition methodology has been developed in a specic context, it is quite general and it can be adapted to other reective languages based on dierent MOPs. Indeed, we have shown how to introduce it in Clos, using the mixins composition technique. As future work, we plan to generalize our methodology to cope with extensions to the MOP and with local protocols used to communicate from the base-level to the metalevel. We argue that extensions to the MOP can be treated in much the same way we do with the current MOP. Insofar as extensions to the MOP are system-wide properties to be observed by all metaobjects, we can take them into account in the composition from the beginning. We would then impose that activating one of these new facilities on an object would necessarily pass through its metaobject and impose rules on their specialized implementations, in much the same way we did with the lookup in the current MOP. An automatic approach to do so can be envisaged. Local extensions are much more involving, since no assumptions can be made at composition time about the local protocols implemented by the com-

15 posed metaobjects. In order to accommodate such local protocols, the composition will have to identify them before composing and ensure that the resulting combined customization respects all the local protocols of the components. One promising avenue we want to look at is to derive new composition models as metalevel operations upon metaobjects, since it is at this level that we can look for information about the local protocols a metaobject implements. Acknowledgments We sincerely thank Nick Edgar for his helpful comments on drafts of this paper. References [1] Aksit, M., Bergmans, L., and Vural, S. An Object-Oriented Language-Database Integration Model: The Composition-Filters Approach. In Proceedings of ECOOP'92 (Utrecht, The Netherlands, June 1992), O. L. Madsen, Ed., Springer-Verlag LNCS 615, pp. 372{395. [2] Andersen, E. P., and Reenskaug, T. System Design by Composing Structures of Interacting Objects. In Proceedings of ECOOP'92 (Utrecht, The Netherlands, June 1992), O. L. Madsen, Ed., Springer-Verlag LNCS 615, pp. 133{152. [3] Berlin, L. When Objects Collide: Experiences with Reusing Multiple Class Hierarchies. In Proceedings of ECOOP/OOPSLA'90 (Ottawa, Canada, Oct. 1990), N. Meyrowitz, Ed., ACM Sigplan Notices, pp. 181{193. [4] Bobrow, D., Gabriel, R., and White, J. CLOS in Context The Shape of the Design Space. In Object-Oriented Programming The CLOS Perspective, A. Paepcke, Ed. MIT Press, 1993, ch. 2. [5] Bracha, G., and Cook, W. Mixinbased Inheritance. Proceedings of OOP- SLA/ECOOP'90, ACM Sigplan Notices 25, 10 (October 1990), 303{311. [6] Chiba, S., and Masuda, T. Designing an Extensible Distributed Language with a Meta- Level Architecture. In Proc. of the 7th European Conference on Object-Oriented Programming (1993), LNCS 707, pp. 482{501. [7] Cointe, P. Meta-classes are First Class: the ObjVlisp Model. In Proceedings of OOP- SLA'87 (Orlando, Florida, Dec. 1987), ACM Sigplan Notices, pp. 156{167. [8] Danforth, S., and Forman, I. Reections on Metaclass Programming in SOM. In Proceedings of OOPSLA'94 (Portland, Oregon, Oct. 1994), ACM Sigplan Notices, pp. 440{ 452. [9] DeMichiel, L. G., and Gabriel, R. P. The Common Lisp Object System: An Overview. In Proceedings of ECOOP'87 (San Diego, California, Sept. 1988), AFCET, pp. 201{220. [10] Graube, N. Metaclass Compatibility. In Proceedings of OOPSLA'89 (New Orleans, Lousiana, Oct. 1989), pp. 305{315. [11] Helm, R., Holland, I. M., and Gandopadhyay, D. Contracts: Specifying Behavioral Compositions in Object-Oriented Systems. In Proceedings of ECOOP/OOPSLA'90 (Ottawa, Canada, Oct. 1990), N. Meyrowitz, Ed., ACM Sigplan Notices, pp. 169{180. [12] Hursch, W. L., and Lopes, C. V. Separation of Concerns. Tech. Rep. NU-CCS-95-03, College of Computer Science, Northeastern University, Boston, MA, Feb [13] Keene, S. E. Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS. Addison-Wesley, Reading, Massachusetts, 1989.

16 [14] Kiczales, G., Ashley, J. M., Jr., L. H. R., Vahdat, A., and Bobrow, D. G. \Object-Oriented Programming: The CLOS Perspective" edited by Andreas Ppcke. The MIT Press, Cambridge, Massachusetts, 1993, ch. Metaobject Protocols: Why We Want Them and What Else They Can Do, pp. 101{ 118. [15] Kiczales, G., des Rivieres, J., and Bobrow, D. G. The Art of the Metaobject Protocol. Cambridge, MIT Press, [16] Lieberherr, K. J. The Art of Growing Adaptive Object-Oriented Software. PWS Publishing Company, Boston, Massachusetts, [17] Maes, P. Concepts and Experiments in Computational Reection. In Proceedings of OOP- SLA'87 (Orlando, Florida, 1987), ACM Sigplan Notices, pp. 147{155. [18] Malenfant, J., Dony, C., and Cointe, P. Behavioral Reection in a Prototype-Based Language. In Proceedings of Int'1 Workshop on reection and Meta-Level Architectures (Tokyo, Nov. 1992), A. Yonezawa and B. Smith, Eds., RISE and IPA (Japan) + ACM SIGPLAN, JSSST & IPS, pp. 143{153. on Object Technologies for Advanced Software (Kanazawa, Japan, Nov. 1993), S. Nishio and A. Yonezawa, Eds., JSSST-JAIST, Springer- Verlag, pp. 128{144. [23] Smith, B. C. Reection and Semantics in Lisp. In Proceedings of the 14th Annual ACM Symposium on Principles of Programming Languages (January 1984), pp. 23{35. [24] Watanabe, T., and Yonezawa, A. Reection in an Object-Oriented Concurrent Language. In Proceedings of OOPSLA'88 (San Diego, California, Sept. 1988), ACM Sigplan Notices, pp. 306{315. [25] Wegner, P. Concepts and Paradigms of Object-Oriented Programming. OOPS Messenger 1, 1 (Aug. 1990). [26] Weinreb, D., and Moon, D. A. Flavors: Message Passing in the Lisp Machine. Tech. Rep. A.I. Memo No. 602, MIT, Articial Intelligence Laboratory, Nov [19] McAffer, J. Meta-Level Programming with CodA. In Proceedings of ECOOP'95 (Aarhus, Danemark, 1995). [20] Moon, D. A. Object-Oriented Programming with Flavors. In Proceedings of OOPSLA'86 (Portland, Oregon, Sept. 1986), ACM Sigplan Notices, pp. 1{8. [21] Mulet, P. Reexion & Langages a prototypes. PhD thesis, Universite de Nantes, Ecole des Mines de Nantes, July [22] Mulet, P., and Cointe, P. Denition of a Reective Kernel for a Prototype-Based Language. In Lecture Notes in Computer Science vol.742: First International Symposium View publication stats