Metaobject

Abstract: The FRIENDS system developed at LAAS-CNRS is a metalevel architecture providing libraries of metaobjects for fault tolerance, secure communication, and group-based distributed applications. The use of metaobjects provides a nice separation of concerns between mechanisms and applications. Metaobjects can be used transparently by applications and can be composed according to the needs of a given application, a given architecture, and its underlying properties. In FRIENDS, metaobjects are used recursively to add new properties to applications. They are designed using an object oriented design method and implemented on top of basic system services. This paper describes the FRIENDS software-based architecture, the object-oriented development of metaobjects, the experiments that we have done, and summarizes the advantages and drawbacks of a metaobject approach for building fault-tolerant systems.

Abstract: AspectS is an approach to general-purpose aspect-oriented programming in the Squeak/Smalltalk environment. Based on concepts of AspectJ it extends the Smalltalk metaobject protocol to accommodate the aspect modularity mechanism. In contrast to systems like AspectJ, weaving and unweaving in AspectS happens dynamically at runtime, on-demand, employing metaobject composition. Instead of introducing new language constructs, AspectS utilizes Smalltalk itself as its pointcut language. AspectS benefits from the expressiveness of Smalltalk, its elegance and power.

Abstract: Object Tcl is an extension to the Tool Command Language (Tcl) for the management of complicated data types and dynamic object-oriented programming in general. We believe it is a worthy alternative to other object-oriented programming extensions (including [incr Tcl]) because it may be used dynamically, allows for per object specialization, has an economy of design and implementation, and provides a metaobject-based class system. Its design was driven by our VuSystem application needs to create a foundation with powerful abstraction and introspection capabilities, yet we sought to retain both the spirit and benefits of Tcl. This paper presents Object Tcl, emphasizing language design and implementation issues by comparing it with alternative systems.

Abstract: 1Programming language design combines the art of invention with judicious adaptationand rejection of ideas previously tried. This chapter presents aspects of the design of theCommon Lisp Object System (CLOS) in the context of related ideas from many languages,providing a view of the CLOS within a broader space of designs.CLOS is the latest in a long history of additions of object-oriented extensions to Lisp. ButCLOS is the first such extension that integrates the type and class systems, and providesa uniform client interface for calling ordinary functions and functions implemented in anobject-oriented style.CLOS is also designed with three constraints not found in other object-oriented exten-sions. The first is to provide essential compatibility with other previously used object-oriented LISP facilities, such as the Symbolics Flavors system. Essential compatibility im-plies an easy path for transforming programs, supporting the most frequently used capabili-ties in such systems. The second constraint is that CLOS is to facilitate experimentation withnew language features in a way that allows them to integrate but not interfere with the kernelof the system. The third is that CLOS kernel facilities are to be efficiently implementable ona wide range of hardware, from special purpose Lisp machine to RISC processors. The CLOSmetaobject protocol[18] supports these three constraints by making available to the user andsystem developer a specification for the interpreter for the language, and an object-orientedprotocol that supports extension. (Actually the metaobject protocol provides only a partialspecification—for only some steps—of the processing of CLOS. If certain customizations ofthose steps are made by the user, the effect is as if the interpreter were customized.)The four sections of this chapter provide four projections of the design space for object-oriented systems. In each, we characterize the range of variability found in current pro-gramming practice, locate CLOS in this context, and then explore extensions that might becoherently added to CLOS. The extensions are important for two reasons. First, a languagemust be judged not only on what it contains, but on what it leaves out. The extensionsare facilities that could have been included in CLOS, but only with the attendant risk ofcomplicating standard practice and reducing understandability. Secondly, these extensionsshow how the CLOS metaobject protocol provides a smooth continuum of capabilities fromsystem developer to user.The first section explores four traditions in which incremental definition of operations hasappeared. These include the object-oriented programming (OOP) languages, data-driveninterpreters, pattern-directed languages, and languages with polymorphism. Incrementaldefinition is important because it supports (i) conceptual separation of the interface and im-plementation(s) of an operation, (ii) extension and specialization of the domain of operationswith new implementations.The second section focuses on the concepts of class and type. It distinguishes five notionsof type and shows different ways the introduction of classes into a language can interactwith the type system. The CLOS choice of making classes support the entire type system isimportant in moving all of Common Lisp towards being object-oriented.The third section on factoring descriptions focuses on use of mixin classes, and on combin-ing and enhancing methods. Factoring descriptions in a programming language is important