J. McAffer. Meta level programming with CodA. In W. Olthoff, editor, Proc. 9th European Conf. on Object-Oriented Programming (ECOOP), pages 190--214. SpringerVerlag, 1995. 65  Home/Search   Document Not in Database   Summary   Related Articles   Check

....programming by the famous work of Pattie Maes [17] It is basically the ability of a system to watch its computation and possibly change the way it is performed. Reflection has been applied to various application domains, such as compilers [13] operating systems [34] distributed systems [19, 2], middleware [15, 1] fault tolerant systems [8] and graphic interfaces [22] An object oriented reflective system is logically structured in two (or more) levels, constituting a reflective tower. The first level is the base level and describes the computation that the system is supposed to do. ....

....reference policy, we refer the interested reader to the source code available on the Reflex website. 8. Related work Using reflection and meta programming to help distributed systems and mobile code is not new. However it is fairly true to say that litterature on the topic is rather scarce. CodA [18, 19], for distributed systems, was one of the first attempt, providing a computational model supporting migration, remote references and replication. The main problem with CodA was that it is an entire execution environment where all objects are controlled by the meta level. The ProActive library [4] ....

J. McAffer. Meta-Level Programming with CodA. In Proceedings of the 9th Conference on Object-Oriented Conference (ECOOP'95), volume 952 of Lecture Notes in Computer Science, pages 190--214. Springer-Verlag, 1995.

....Reflection. The computation of objects A, B and C transfers control to the meta level Each object in the base level will be supported by a set of meta objects. Each one of them will describe some aspect of the base level behavior of the object. This is a popular idea already studied in [13] and [14]. In SO4, the object environment can be subdivided in three different meta objects: Scheduler meta object. It contains a set of ready threads in the object. It can schedule them and decides which one is the most adequate to execute. Communication meta object. It takes charge of sending and ....

J. McAffer. Meta-Level Programming with CodA. 9 th European conference on Object-Oriented Programming (ECOOP?95). Aarhus (Denmark), 1995.

....the queue length and the dispatching algorithm can be dynamically changed using the environment MOP. 7 Related Work There has been a growing interest in using reflection to achieve adaptation at the middleware level. A pioneering work in this area has been the CodA meta level architecture[16]. CodA decomposes the meta level in a set of fine grained components that reify aspects such as message sending, acceptance and execution. However, it is difficult to support unanticipated changes in the meta level due to the tight coupling of components. In the FlexiNet [12] project, researchers ....

J. McAffer. Meta-level Programming with CodA. In Proceedings of 9th European Conference on Object-Oriented Programming (ECOOP'95), volume 952 of Lecture Notes in Computer Science, pages 190--214. Springer-Verlag, 1995.

....in turn involves the suspension of their corresponding underlying processing resources, e.g. threads. 8 Related Work There has been a growing interest in using reflection to achieve adaptation at the middleware level. A pioneering piece of work in this area was the CodA meta level architecture[18]. CodA decomposes the meta level in to a set of finegrained components that reify aspects such as message sending, acceptance and execution. However, it is difficult to support unanticipated changes in the metalevel due to the tight coupling of components. In the FlexiNet [13] project, ....

J. McAffer. Meta-level Programming with CodA. In Proceedings of 9th European Conference on Object-Oriented Programming (ECOOP'95), volume 952 of Lecture Notes in Computer Science, pages 190--214. Springer-Verlag, 1995.

....a sufficient basis to implement the dynamic adaptation. Therefore, any system which provides mechanisms similar to these presentations are well suited for dynamic adaptation. Examples are, Mircrosoft s Component Object Model [MD95] Java [GYS96] or any reflective system [Mae87] such as CodA [McA95], McA96] SOM [Lau94] or Geo [BGR96] BR96] 6 Summary Interoperability between components is a major issue in software development. Interoperability means plug compatibility between the involved components regarding interfaces as well as semantics [Weg96] To achieve interoperability it is ....

McAffer J. "Meta-level programming with CodA". In ECOOP `95 Conference Proceedings. Springer Verlag, 1995.

....scheduling and load balancing) with the whole expressive power of a full programming language [54] as opposed to some global and fixed algorithm (which is usually optimized for a specific kind of application or an average case) 5. 3 Examples of Meta Object Protocols (MOPs) The CodA architecture [48] is a representative example of a general object based reflective architecture (i.e. a MOP) based on meta components 12 . CodA considers by default seven (7) meta components, associated to each object (see Fig. 2) corresponding to: message sending, receiving, buffering, selection, method ....

....Simtalk, Actalk, GARF, and CodA itself [18] 5.4 Examples of Applications To illustrate how reflection may help at mapping various computation models and protocols onto user programs, we will quickly survey some examples of experiments with a specific reflective architecture. We chose CodA. See [48] for a more detailed description of its architecture and libraries of components. Note that, in the case of the CodA system, as well as for almost all other examples of reflective systems further described, the basic programming model is integrative, while reflection enables the customization of ....

[Article contains additional citation context not shown here]

J. McAffer, Meta-Level Programming with CodA, European Conference on Object Oriented Programming (ECOOP'95), edited by W. Olthoff, LNCS, n o 952, Springer-Verlag, August 1995, pages 190--214.

....of relying on proxies) and on the receiver side incoming messages can be synchronized. Many existing MOPs do not allow the behavior of message senders to be modified. Hence, such a distribution strategy cannot be implemented using reflection in these systems. Some systems (see, for instance CODA [aff95]) provide access to senders right from the start. Therefore, they can introduce an overhead for local applications. In this paper, we present a reification mechanism for object oriented interpreters based on program transformation techniques. We use a generic transformation which can be applied ....

.... the composition lookupMethod( apply( So, the behavior of the receiver of a method call can be modified easily by changing the definition of lookupMethod( as illustrated by trace insertion in the Section 5) However, a modification concerning the sender of the method call (see CODA [aff95] for a motivation of making the sender explicit in the context of distributed programming) is much more difficult to implement. Such a change would require the modification of all instances of ExpMethod in the abstract syntax tree, i.e. all occurrences of the operator . Indeed, we have to check ....

J. McAffer. Meta-Level Programming with CODA. Proceedings of ECOOP, LNCS 952, Springer Verlag, pp. 190-214, 1995.

....creation Statement sequencing no return but calls of continuations define new control structures Exceptions make stack explicit (based on previous transf. define retry mechanisms Table 1: Reifiable features two parts: send( on the message sending side and receive( on the receiver side (see [mca95] for a motivation) Our technique is inspired from previous work on METAJ [met99] a reflective JAVA interpreter based on Smith s tower based interpreting method. METAJ also features selective reification of reflective capabilities but introduces an interpretation layer everywhere in a program. ....

J. McAffer. Meta-level Programming with CODA. ECOOP, LNCS 952, Springer Verlag, 1995.

....and load balancing) with the whole expressive power of a full programming language [OI 94] as opposed to some global and fixed algorithm (which is usually optimized for a specific kind of application or an average case) 5. 3 Examples of Meta Object Protocols (MOPs) The CodA architecture [McA 95] is a representative example of a general object based reflective architecture (i.e. a MOP ) based on meta components 13 . CodA considers by default seven (7) meta components, associated to each object, corresponding to: message sending, receiving, buffering, selection, method lookup, ....

....as Simtalk, Actalk, GARF, and CodA itself. 5.4 Examples of Applications To illustrate how reflection may help at mapping various computation models and protocols onto user programs, we will quickly survey some examples of experiments with a specific reflective architecture. We chose CodA. See [McA 95] for a more detailed description of its architecture and libraries of components. Note that, in the case of the CodA system, as well as for almost all other examples of reflective systems further described, the basic programming model is integrative, while reflection enables the customization ....

[Article contains additional citation context not shown here]

J. McAffer, "Meta-Level Programming with CodA," European Conference on Object Oriented Programming (ECOOP'95), edited by W. Olthoff, LNCS, n o 952, Springer-Verlag, August 1995, pages 190--214.

....network protocol for delivering a message to its target. Other examples of adaptative policies could be the implementation of a memory management suitable for the object granularity [YMFT91] Some other examples of MOPs providing a set of control metaobjects at the metalevel are Muse, CodA [McA95] Iguana [GC96] AL 1 D [OIT92] Actalk and so on. Note that some of them also provide structural reflection oriented metaobjects that can be used to process a certain kind of introspection especially in Iguana. One of the most simple example of behavioral reflective architecture is the ....

....by a class or even instances or methods. The problem of these kinds of approaches is that they force the programmer to think about the kind of meta level information he needs to implement his base program. This kind of approach, generally called fine grained MOPs it can also be found in CodA [McA95] Apertos [Yok92] Muse [YTM 91] and Actalk [Bri89] provides a complex and sometimes difficult to use meta interface (implicit, explicit and inter MOP [Zim96] Some more transparent techniques has been studied in CLOS or 3 KRS like MOPs. Those intelligent techniques, are trying to ....

[Article contains additional citation context not shown here]

J. McAffer. Meta-level programming with CodA. In Proceedings of the 9th European Conference on Object-Oriented Programming (ECOOP'95), volume 952 of Lecture Notes in Computer Science, pages 190--214. Springer-Verlag, August 1995. 123

....explicit dynamic linking and concurrency. In [24] a transaction framework is presented that provides ways to dynamically adapt the transaction semantics of a system for optimal transactional behaviour at all times. This work shows the feasibility of dynamic exchange of transaction policies. Coda [14] has been used to open up the implementation of Smalltalk message passing and is able to add meta level infrastructure to Smalltalk objects, so that additional behaviour such as concurrency or distribution can be added. The Coda experiment is especially important as it shows that a meta level is ....

McAffer, J., "Meta-level Programming with CodA, " Proceedings ECOOP'95, Olthoff, W. (Ed.), LNCS 952, Springer-Verlag, Aarhus, Denmark, August 1995, pp. 190-214.

.... method signature, as in TAO, or as precondition style statements within a method body, such as in CEiffel [Lh92] and CEE [Jal93] The guard may be written completely separate from the functional code, such as the coordinator of COOL, the behavioural class of DRAGOON or as part of the meta level [McA95]. The differences between these approaches usually only become significant when reuse issues are considered and we wish to decouple the synchronisation part of an object from the functional part. Complete decoupling of synchronisation and functional code leads to a corresponding separation of ....

....reception criteria you simply define a new type of message object. Although pertaining most obviously to active object systems, any concurrent object oriented language which either delegates messages to a controller object [Fro93] or uses a form of metalevel interception of method dispatch [Ber94, McA95], will also have a similar message processing loop. In such languages, however, the compiler takes care of generating the appropriate message processing logic not the programmer and so no anomaly occurs. 2.4.3 Generalised Body Anomaly We can generalise the body anomaly to any situation where ....

[Article contains additional citation context not shown here]

McAffer J., "Meta-level Programming with CodA", Proceedings of the 9 th European Conference on Object-Oriented Programming (ECOOP `95), LNCS 952, Springer-Verlag, pp190-214, August 1995

.... method signature, as in TAO, or as precondition style statements within a method body, such as in CEiffel [Lh92] and CEE [Jal93] The guard may be written completely separate from the functional code, such as the coordinator of COOL, the behavioural class of DRAGOON or as part of the meta level [McA95]. The differences between these approaches usually only become significant when reuse issues are considered and we wish to decouple the synchronisation part of an object from the functional part. Complete decoupling of synchronisation and functional code leads to a corresponding separation of ....

....reception criteria you simply define a new type of message object. Although pertaining most obviously to active object systems, any concurrent object oriented language which either delegates messages to a controller object [Fro93] or uses a form of metalevel interception of method dispatch [Ber94, McA95], will also have a similar message processing loop. In such languages, however, the compiler takes care of generating the appropriate message processing logic not the programmer and so no anomaly occurs. 2.4.3 Generalised Body Anomaly We can generalise the body anomaly to any situation where ....

[Article contains additional citation context not shown here]

McAffer J., "Meta-level Programming with CodA", Proceedings of the 9 th European Conference on Object-Oriented Programming (ECOOP `95), LNCS 952, Springer-Verlag, pp190-214, August 1995

.... experiments with actual programs within a sophisticated programming environment (Smalltalk 80 based) to help at developing and monitoring them [LBB 91] The component based architecture of an Actalk active object is close to the component based meta architecture of CodA, designed by Jeff McAffer [McA 95] CodA provides finer grain components and more refined interface between them, but at the cost of more complexity. There are also other alternatives to components and methods decomposition, as for instance with parameterizing the invocation of some methods via arguments, as advocated by the ....

....it reaches some limitations when combining differents versions of a same component (in the context of this paper, the activity synchronization component) The programmer may have then to rely on some amount of explicit combination. A finer grain decomposition of components, as proposed by CodA [McA 95] brings more independence and modularity, but it also still relies on a single component to cover activity and synchronization concerns. Our belief is that it is difficult anyway to further decompose a complex aspect, such as activity synchronization, in fully orthogonal pieces. In other words, ....

[Article contains additional citation context not shown here]

J. McAffer, "Meta-level Programming with CodA," Proc. of ECOOP'95, edited by W. Olthoff, LNCS, n o 952, Springer-Verlag, August 1995, pages 190--214.

....as data something representing the state of the program during its own execution [4] The goal of reflection is to allow users programs to reason about their own execution state and eventually alter it to change their own meaning. Several object oriented reflective 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 defines the set of metaobjects as well as the interactions between them ....

....constraints at the metalevel. Practically, MOPs usually offer customizable functionalities, as a set of elementary bricks, which only have to be assembled together so as to define 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 first class entity of the language. still ....

McAffer, J. Meta-Level Programming with CodA. In Proceedings of ECOOP'95 (Aarhus, Danemark, 1995).

....1990a , Caromel 1993b ] also used a metalevel for reification. MOPs have a wide scope of applications, and are an active field of research for parallel and distributed programming [Chiba Masuda 1992 , Watanabe Yonezawa 1988 , Yokote Tokoro 1986 , Madany et al. 1992 , Buschmann et al. 1992 , McAffer 1995 , Chiba 1995 ] Work using more traditional methods, such as proxy generators, are closely related [Birrell et al. 1995 ] 6.2. A MOP for C : Basic Classes The first principle of our MOP for C is embodied in a special class, called Reflect. All classes inheriting publicly from Reflect, ....

J. McAffer. Meta-level Programming with CodA. In Proceedings of the Ninth European Conference on Object-Oriented Programming (ECOOP'95), (Aarhus, Denmark), August 1995. also available from ftp://camille.is.s.u-tokyo.ac.jp/pub/members/jeff/docs/ecoop95. a4.ps.gz.

....to actually redefine the body purely on the basis of message reception criteria. Although pertaining most obviously to active object systems, any concurrent object oriented language which either delegates messages to a controller object [Fro93] or uses meta level interception of method dispatch [Ber94, McA95] , will also have a similar message processing loop. However in such languages the compiler takes care of generating the appropriate message processing logic, not the programmer and so no anomaly occurs. 4.1.2 Generalised Body Anomaly The body anomaly can be generalised to any situation where ....

....with as little additional coding as possible. This can be done in a number of ways depending on the actual language used. A common way is to write wrappers for the base methods in the derived class, so that the wrappers maintain the additional state information [Mit95] In meta level approaches [Ber94, McA95] it is quite simple to intercept messages to maintain the same information. In both cases, but more so with wrappers) we must ensure that the only way to invoke the base message is through the wrapper or modified meta level; for wrappers, such a requirement is met by a language such as Java, but ....

McAffer J., "Meta-level Programming with CodA" , in Proceedings of the European Conference on Object-Oriented Programming (ECOOP 95), Springer-Verlag, August 1995

....flexible abstractions for software concerns. The separation of concerns forces their later composition. Two perspectives exist regarding concern composition: orthogonal and non orthogonal. The orthogonal perspective considers abstractions to be completely orthogonal being enough to join them [1, 5, 16], e.g. join them sequentially, while the non orthogonal perspective considers that concern composition must consistently integrate the abstractions parts exhibiting semantic overlapping [18, 12] Note that the orthogonal compositionperspective is domainindependent, since there is no semantic ....

....which are not completely orthogonal. In our opinion, this problem arises from not defining two composition levels, for composition and customization are carried out using the meta interface. The decomposition in components of finer granularity, proposed in the CodA reflective architecture [16] seeks to avoid the problems of abstraction composition. CodA defines seven meta objects: send, accept, queue, receive, protocol, execution, and state. The seven meta objects which form the architecture must be customized and composed among themselves in order to support the required concerns. Due ....

[Article contains additional citation context not shown here]

J. McAffer. Meta-level Programming with CodA. In ECOOP '95, pages 190--214, Aarhus, Denmark, August 1995.

....in its initial stages. OpenC [1] does not provide direct support for composition. MOOSTRAP [6] and MetaXa [2] formerly known as MetaJava) support sequential composition of similar metaobjects. We say that meta objects are similar if they implement the same interface. Apertos [11] and CodA [5] admit composition of dissimilar meta objects, through an extensible set of meta level aspects. In order to introduce new aspects, pre existing ones must be modified, and these modifications may clash. Guaran a [9] allows similar meta objects to be combined through the use of composer ....

J. McAffer. Meta-level programming with CodA. In ECOOP'95, pages 190--214, Aug. 1995.

....for each object. A metaobject is responsible for a welldefined task (like sending a message) and is not always attached 1 to the baseobject. By this way, the programmer can control some well known aspects of an object and limit the overhead due to the meta level. The problem of those approaches [McA95] OIT93] is that they complexify the meta level programming by introducing many sophisticated and generic meta level concepts. To keep the advantages of the fine grained approaches (that allow the programmer to implement several control aspects independently) without complexifying the meta ....

J. McAffer. Meta-level programming with CodA. In Proceedings of ECOOP'95, volume 952 of LNCS, pages 190--214. Springer-Verlag, August 1995.

....of adjustment definitions, is based on the ClassCombiner mechanism for behavior combination, presented in [13, 15] From the description above it should be evident that in contrast to most of the existing MOPs, we do not use inheritance as the modification technique at the metalevel. In [11, 14] it has been argued that subclassing is not the most appropriate technique for organizing the meta level, since a new subclass must be created for each possible combination of specialization constraints, ending up with the combinatorial explosion problem. Additionally, in contrast to the ....

....populated classes problem. Additionally, the multiple inheritance graph imposes an artificially conflicting relationship between both specialize: redefinitions which must be resolved manually. Last but not least, no means is provided for supporting exclusion. The metaobject protocol of CodA [11] also has a finegrained structure, which makes it similar to our model. However, there is a substantial difference between the two models. In CodA, meta level components are objects which interact with each other by means of message sending. In our model, adjustments are only declarative ....

[Article contains additional citation context not shown here]

McAffer J.. Meta-Level Programming with CodA. In Proceedings of ECOOP '95, LNCS 952, pp. 190-- 214. Springer-Verlag, 1995.

....variable since create object is at the meta level. Any base level entity must be dealt with through built in meta functions. Other object oriented reflective languages include ABCL R [61, 41, 40] Ferber s language [21] RbCl [32] The MIP for C [9] OpenC version 1 [13] AL 1 D [46, 45] CodA [42], a reflective version of BETA [6] and Iguana [29, 30] They have explored various applications of the meta 5 Again, we use an altered version of 3 KRS for clarifying our argument. CHAPTER 3. TECHNIQUES FOR PROCESSING A PROGRAM 27 architecture. ABCL R is a parallel language, and it allows ....

McAffer, J., "Meta-level Programming with CodA," in Proc. of the 9th European Conference on Object-Oriented Programming, LNCS 952, pp. 190--214, Springer-Verlag, 1995.

No context found.

J. McAffer. Meta level programming with CodA. In W. Olthoff, editor, Proc. 9th European Conf. on Object-Oriented Programming (ECOOP), pages 190--214. SpringerVerlag, 1995. 65

No context found.

McAffer, J. : Meta-Level Programming with CodA. In proceedings of ECOOP95 (1995).

No context found.

McAffer J. 1995. Meta-Level Programming with CodA. In W. Olthoff, (ed.), Proceedings of the 9th European Conference on Ob ject-Oriented Programming (ECOOP '95), LNCS 952, pp.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC