Danforth S, Forman IR. Reflection on metaclass programming in SOM. Conference Proceedings of Object-Oriented Programming Systems, Languages and Applications, Portland, Oregon, USA, October 1994. ACM Press, 1994; 440--452.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....or redefinitions of existing code. System extensions or modifications by developers are thus non intrusive and portable on any proper Clos implementation. This approach of using the product of a system s implementation to construct that very product is called metacircular [Coi87, Gra88, DF94] the language to extend Clos is Clos itself. Any Clos program at the base level or at the metalevel extends and redefines the system. Extending the Clos MOP Clos relies upon two relationships in the language kernel: generalization between subclasses and classes, and instantiation between ....

S. Danforth and I. Forman. Reflections on metaclass programming in SOM. In OOPSLA94 [OOP94], pages 440--452. ACM SIGPLAN Notices 29(10), 1994.

....The first relates to the type hierarchy imposed by the use of a class wrapper, and the second relates to inheritance of metaobject classes. We feel that such implications of inheritance are often neglected in implementations of reflective languages, with the notable exception of CLOS [20] and SOM [9]. We discuss each problem below. The first problem is that the class wrapper that we create to logically wrap the base class does not share the same type hierarchy as the baselevel class. Instead it extends the metalevel type hierarchy in order to inherit the metaobject implementation. In order ....

....is present, Java does not see that the class wrapper is a subtype. This could lead to problems with existing client code. Ideally the type hierarchy of the class wrapper should reflect the baselevel application level type hierarchy. The second problem is the well known meta constraint problem [9]. If a class that is bound to a metaobject class is extended by another class and that class is bound to a different metaobject class then there should be some way of sensibly resolving the effect of both metaobject classes on the resultant class. In Dalang the methods inherited from the ....

[Article contains additional citation context not shown here]

Danforth, S. H. and Forman, I. R. : Reflections on Metaclass Programming in SOM. In proceedings of OOPLSA'94(1994).

....which are designed according to the black box principle: their metalevel is hidden behind the functionality interface, and there is no possibility to influence it. Examples of such languages are C [25] and Eiffel [16] Languages of the second category such as CLOS [10] Smalltalk 80 [7] SOM [6], ObjVlisp [4] or Open C [3] follow a metaobject protocol [10] approach to the design of the metalevel. Along the decomposition of the application into class definitions there is a decomposition of the metalevel into class objects, each encapsulating the local metalevel of the corresponding ....

Danforth S. and Forman I. Reflections on Metaclass Programming in SOM. In Proceedings OOPSLA '94, ACM SIGPLAN Notices, Vol. 29, No. 10, p. 440--452, 1994.

....the links on the controlled object and the behavior of its meta object. For example, how manage at the same time a inheritance link and a link that implies standard control This problem is quite similar to problems due to the inadequacy between meta classes and classes presented in [Gra89, SD94] and it outlines the need of composition between meta objects (when it is possible) MM] 10 ....

Ira R. Forman Scott Danforth. Reflections on metaclass programming in som. In ACM, editor, Proceedings of OPPSLA'94, volume 29 of ACM Sigplan Notices, pages 440--452, Portland, October 1994. ACM.

....these initarg keywords at creation time. 3 core are reset. We chose this simple example to clearly present the intrinsic aspects of flo s links, a curious reader may refer to [13, 14] 2. 2 The standard message passing control by means of metaobjects Amongst the multiple OO meta level proposals [1, 8, 3, 25, 7, 11, 31], the metaobjects as defined by Maes (in [28] are well adapted to implementing the flo dependency management because they allow abstraction of the computation of an object. The metaobject holds information about the implementation and interpretation of the object. It is possible to create ....

....the correspondence between the links on the controlled object and the behavior of its metaobject. For example, how to manage at the same time an inheritance link and a link that implies standard control This problem is quite similar to problems due to the metaclass compatibilities presented in [20, 11] and it outlines the need of composition between metaobjects (when it is possible) 33] Acknowledgments We like to thank Jacques Malenfant for his remarks on the earlier version of this paper and Philippe Mulet for our exciting discussions on the bootstrapping choices of the flo kernel. ....

S. Danforth and I. R. Forman. Reflections on metaclass programming in SOM. In ACM, editor, Proceedings of OOPSLA'94, volume 29, pages 440--452, Portland, Oct. 1994. ACM.

....inspection capabilities [JavaSoft96] Finally, a number of other reflective languages are worthy of note. For example, the language Smalltalk 80 has a number of reflective features [Goldberg83, Rivard96] Other notable contributions have been made from 3 KRS [Maes87] Agora [Steyaert94] and SOM [Danforth94, Forman94]. 4.2. Reflective Systems 4.2.1. Apertos Apertos was the first attempt to exploit reflection in an operating system. The motivation for this work was to provide more flexible operating systems that can adapt to their environment, e.g. in mobile systems [Yokote92] The architecture of Apertos ....

Danforth, S., I. R. Forman, "Reflections on Metaclass Programming in SOM", In Proceedings of OOPSLA'94, pp440-452, ACM, 1994.

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

Danforth, S., and Forman, I. Reflections on Metaclass Programming in SOM. In Proceedings of OOPSLA'94 (Portland, Oregon, Oct. 1994), ACM Sigplan Notices, pp. 440-- 452.

....our work aims also at object customizations regarding algorithmic strategies. Besides, in ABCL R3 the customization is achieved through a chain of operational definitions of how to interpret base level expressions (executors) In general, such operational style of extension is not efficient. In SOM[14] or CLOS[38] reflection principles are used for changing object behavior, by invoking the methods available to create and initialize classes, to compose their methods tables, etc. Namely, object descriptions may be altered at runtime by invoking the inherited methods that deal with class objects, ....

S. Danforth and I. Forman. Reflections on Metaclass Programming in SOM. In Proc. of OOPSLA'94, pages 440--452. ACM Press, October 1994.

....dependency management is not completely safe. Indeed, the success of our approach is based on the correspondence between the dependencies on the controlled object and the behavior of its metaobject. This problem is quite similar to problems due to the metaclass compatibility presented in [Gra89, SD94] and it outlines the need of composition between meta objects (when it is possible) MMC] 4 Related work Multiple attempts to express and to ensure consistency of dependencies between objects exist, and we present here the most significant ones. Standard controller Corresponding Controller ....

Ira R. Forman Scott Danforth. Reflections on metaclass programming in SOM. In ACM, editor, Proceedings of OOPSLA'94, volume 29 of ACM Sigplan Notices, pages 440--452, Portland, October 1994. ACM.

....what an object does (the base level) from how it does it (its meta level) McA 95] A reflective language encourages a clean separation between the basic functionalities of the application from its representations and controls. In class based languages integrating reflective features [COI 87] DAN 94] the class of a class a metaclass defines some properties concerning object creation, encapsulation, inheritance rules, message handling, etc. We call class properties the properties that denote behavior for classes themselves, independently from the behavior for their instances. In [LED ....

DANFORTH S., FORMAN I.R. --- Reflections on Metaclass Programming in SOM. In Proceedings of OOPSLA'94, ACM Sigplan Notices, Portland, Oregon, October 1994.

....any request it has made to be satisfied. In other words, the program is blocked. 6 Related work A number of proposals for generic distributed object management architectures have been developed, such as the the Common Object Request Broker Architecture (CORBA) defined by OMG[COR95] and the SOM[DF94, Lau94] product family which provide for communications among objects in different processes on the same or different systems. CORBA was designed to provide a general purpose infrastructure to enable the use of distributed objects in a wide variety of client server applications. It provides a ....

....To provide language neutrality, SOM defines a runtime API that is based on few external procedures and simple data structures that are required by client processes. This API is used by programmers to create and use SOM objects according to a traditional objectoriented model of computation [DF94] SOM s distributed framework a set of system SOM classes allows methods to be invoked (in a transparent way) on SOM objects that exist in different address spaces from the calling program. Distributed SOM conforms to the OMG s basic architecture for CORBA compliant systems by allowing ....

S. Danforth and I.R. Forman. "Reflections on metaclass programming in SOM". In Proceedings, Conference on Objectoriented Programming Systems, Languages and Applications -- OOPSLA'94, Portland, Oregon, 1994.

.... according to orthogonal functionality (metaregions) Metaobject control and reflection are well known technique used to design flexible dynamic adaptive programming system in object oriented programming ( KRB91] MJD96] Some popular programming system are based on this technique ( FDM94] [DF94], NH96] Sometimes metaobjects play the role of mediators between communicating objects [GC96] This project assumes metaobjects to be specialized according to reification kinds: object methods invocation, access to object state, access to program code at run time, etc. Transformation of object ....

Scott Danforth, Ira R. Forman. Reflections on Metaclass Programming in SOM. 20 OOPSLA 94- 10/94 Portland, Oregon USA

....allows one to construct applications that are more dynamic, and provides avenues for integration of diverse applications. Open implementations [11, 13] of class libraries, for instance, will be most natural when using object introspection. Some object packaging frameworks, most notable SOM [3, 7, 8] and COM [20] add object introspection and reflection to the C programming language. However, applications using these frameworks each must follow some prescribed class hierarchy. For example, SOM requires all classes with SOM capability to derive from the SOMObject class, and COM requires all ....

Scott Danforth and Ira R. Forman. Reflection on metaclass programming in SOM. In Conference proceedings of Object-Oriented Programming Systems, Languages and Applications, pages 440-- 452. Portland, Oregon, USA, October 1994. ACM Press.

....allows one to construct applications that are more dynamic, and provides avenues for integration of diverse applications. Open implementations [11, 12] of class libraries, for instance, will be most natural when using object introspection. Some object packaging frameworks, most notable SOM [3, 7, 8] and COM [19] add object introspection and reflection to the C programming language. However, they require applications using these frameworks to follow their respective class hierarchy. For example, SOM requires all classes with SOM capability to derive from the SOMObject class, and COM all ....

Scott Danforth and Ira R. Forman. Reflection on metaclass programming in SOM. In Conference proceedings of Object-Oriented Programming Systems, Languages and Applications, pages 440-- 452. Portland, Oregon, USA, October 1994. ACM Press.

....For this reason, metaclass composition is a hard problem to deal with, which currently imposes strong assumptions on metaclasses so as to ensure their reusability. In the SOM system [SOM93] this open issue is tackled by the automatic derivation of new metaclasses ensuring compatible composition [DF94]. However the price is very high, since these derived metaclasses are implicitly introduced, and specially handled by the system (i.e. impose new semantics for message passing using a precedence list) thereby breaking the harmony of an uniform hierarchy of explicit metaclasses. In Classtalk, an ....

Scott Danforth and Ira R. Forman. Reflections on Metaclass Programming in SOM. In Proceedings of OOPSLA'94, Portland, Oregon, October 1994. 15

....efficient, configurable program and operating system abstractions may be implemented. Recent work on reflective programming[43] partly performed concurrently with our research is now leading researchers to offer abstractions like meta objects , which are similar to the policy objects used in CTK[14]. Both approaches provide mechanisms for changing an object s behaviors dynamically in most of its aspects (object creation, method invocation, etc) but in general, metaobject protocols address configuration problems for which efficient runtime configuration is not crucial. For example, in ....

....such that changes in object behavior persist despite object migration among different meta object spaces. The resulting required runtime checking of meta object compatibility is too computationally expensive for applications in which configuration may be highly dynamic or short lived. In SOM[14] or CLOS[51] reflection principles are used for changing object behavior by invoking the methods available to create and initialize classes, to compose their methods tables, etc. As a result, object descriptions may be altered at runtime by invoking the inherited methods for dealing with class ....

S. Danforth and I. Forman. Reflections on metaclass programming in SOM. In Proc. of OOPSLA'94, pages 440--452. ACM Press, October 1994.

....ComputeMetaclassName ( to customize the policy. In the case where a class has more than one base class and the class metaobjects for them give different metaclasses, we simply raise a compilation error. Other researchers have proposed automatic derivation of a mixed in metaclass in this case [5], but applying that idea to the OpenC MOP is not straightforward because combining the same member function of two metaclasses is not always possible. Syntax extension The OpenC MOP provides limited ability to extend the language syntax. The programmer can register new keywords, which can ....

Danforth, S. and I. R. Forman, "Reflections on Metaclass Programming in SOM," in Proc. of ACM Conf. on Object-Oriented Programming Systems, Languages, and Applications, pp. 440--452, 1994.

....among the first languages to have method wrappers. Wrappers in CLOS are different than in P as they are defined on a per operation basis. A model of wrappers that is closer to P is that of SOM metaclasses, where all (or selected) operations of a class can be wrapped by before and after methods [Dan94, For94]. Wrappers are defined in SOM by overriding the dispatch methods of metaclasses. Thus, to define the equivalent of the P monitor component would require four separate definitions in SOM: two classes (cursor and container) and two metaclasses (a metaclass for wrapping cursor operations and a ....

S. Danforth and I. Forman, "Reflections on Metaclass Programming in SOM", OOPSLA 1994, 440-452.

....can have total freedom to use a specific metaclass for each class. So, they can assign specific properties to classes, but the trade off is that they need to be always aware of the compatibility issue. 3. 2 SOM SOM is an IBM CORBA compliant product which is based on a metaclass architecture [DF94b] The SOM kernel follows the ObjVlisp model [Coi87] SOM metaclasses are explicit and can have many instances. Therefore, users have complete freedom to organize their metaclass hierarchies. 3.2.1 Compatibility issue in SOM SOM encourages the definition and the use of explicit metaclasses by ....

Scott Danforth and Ira R. Forman. Reflections on Metaclass Programming in SOM. In Proceedings of OOPSLA'94, pages 440--452, October 1994.

.... according to orthogonal functionality (metaregions) Metaobject control and reflection are well known technique used to design flexible dynamic adaptive programming system in object oriented programming ( KRB91] MJD96] Some popular programming system are based on this technique ( FDM94] [DF94], NH96] Sometimes metaobjects play the role of mediators between communicating objects [GC96] This project assumes metaobjects to be specialized according to reification kinds: object methods invocation, access to object state, access to program code at run time, etc. Transformation of object ....

Scott Danforth, Ira R. Forman. Reflections on Metaclass Programming in SOM. OOPSLA 94- 10/94 Portland, Oregon USA

....multiple inheritance, both behavioral conflicts and coherency issues could arise at run time. To address behavioral conflicts, SOM proposes a metaclass cooperation framework providing a programming model in which metaclasses can be composed by combining different methods into a cooperation chain [DF94b]. In fact, the cooperation framework applies to intra metalevel composition. Because it is based on multiple inheritance, it suffers from all drawbacks described above in section 2.2. Finally, SOM proposes a partial solution to the inter metalevel composition issue. With the derived metaclasses ....

Scott Danforth and Ira R. Forman. Reflections on Metaclass Programming in SOM. ECOOP'96 7 In Proceedings of OOPSLA'94, Portland, Oregon, October 1994.

No context found.

Danforth S, Forman IR. Reflection on metaclass programming in SOM. Conference Proceedings of Object-Oriented Programming Systems, Languages and Applications, Portland, Oregon, USA, October 1994. ACM Press, 1994; 440--452.

No context found.

Scott Danforth and Ira Forman. Reflections on metaclass programming in SOM. In Proc. of OOPSLA'94, pages 440--452. ACM Press, October 1994.

No context found.

Scott Danforth and Ira R. Forman, Reflections on Metaclass Programming in SOM, " in proceedings of OOPSLA'94, Portland, pp. 440-452.

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