Jump to content

Metaobject: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
m Per Wikipedia Style Manual: corrected heading capitalization, removed needless piping from 1 link. Clarified idea by making sentences more alike.
Line 7: Line 7:
A '''metaobject protocol''' (MOP) is an [[Interpreter (computing)|interpreter]] of the [[semantics]] of a program that is open and extensible. Therefore, a MOP determines what a program ''means'' and what its behavior is, and it is extensible in that a programmer (or [[Metaprogramming|metaprogrammer]]) can alter program behavior by extending parts of the MOP. The MOP exposes some or all internal structure of the interpreter to the programmer. The MOP may manifest as a set of classes and methods that allow a program to inspect the [[state (computer science)|state]] of the supporting system and alter its [[behaviour]]. MOPs are implemented as [[object-oriented programming|object-oriented]] programs where all objects are metaobjects.
A '''metaobject protocol''' (MOP) is an [[Interpreter (computing)|interpreter]] of the [[semantics]] of a program that is open and extensible. Therefore, a MOP determines what a program ''means'' and what its behavior is, and it is extensible in that a programmer (or [[Metaprogramming|metaprogrammer]]) can alter program behavior by extending parts of the MOP. The MOP exposes some or all internal structure of the interpreter to the programmer. The MOP may manifest as a set of classes and methods that allow a program to inspect the [[state (computer science)|state]] of the supporting system and alter its [[behaviour]]. MOPs are implemented as [[object-oriented programming|object-oriented]] programs where all objects are metaobjects.


=== Runtime and Compile time ===
=== Runtime and compile time ===
MOPs may be [[Run time (computing)|runtime]] or [[compile time]]. The metaobjects of runtime MOPs exist while the program itself is executed. The metaobjects of compile-time MOPs, however, exist only when the program is compiled. They may alter or extend the compiling process, but do not exist when the program is running.
MOPs may be [[Run time (computing)|runtime]] or [[compile time]]. The metaobjects of runtime MOPs exist while a program is running, or executing. Instead, the metaobjects of compile-time MOPs exist only while a program is compiled. They may alter or extend the compiling process, but do not exist when the program is running.


One of the best-known runtime MOPs is the one described in the book ''[[The Art of the Metaobject Protocol]]'' (often referred to as AMOP); it applies to the [[Common Lisp]] Object System ([[Common Lisp Object System|CLOS]]) and allows the mechanisms of [[inheritance (computer science)|inheritance]], [[method dispatch]]ing, [[instantiation (computer science)|class instantiation]] and so on to be manipulated. At [[Xerox PARC]], one of the authors of AMOP, [[Gregor Kiczales]], developed a small but powerful MOP-based runtime object system in [[Scheme (programming language)|Scheme]] called TinyCLOS.<ref name="metahelix">Shigeru Chiba, Gregor Kiczales and John Lamping, ''[http://www2.parc.com/csl/groups/sda/publications/papers/Chiba-ISOTAS96/for-web.pdf Avoiding Confusion in Metacircularity: The Meta-Helix]'' in Proceedings of the Second JSSST International Symposium on Object Technologies for Advanced Software, [[Kanazawa, Ishikawa|Kanazawa]], Springer-Verlag LNCS 1049, pp 157-172, 1996</ref> which has been ported to many Scheme implementations.
One of the best-known runtime MOPs is the one described in the book ''[[The Art of the Metaobject Protocol]]'' (often referred to as AMOP); it applies to the [[Common Lisp]] Object System ([[Common Lisp Object System|CLOS]]) and allows the mechanisms of [[inheritance (computer science)|inheritance]], [[method dispatch]]ing, [[instantiation (computer science)|class instantiation]] and so on to be manipulated. At [[Xerox PARC]], one of the authors of AMOP, [[Gregor Kiczales]], developed a small but powerful MOP-based runtime object system in [[Scheme (programming language)|Scheme]] called TinyCLOS.<ref name="metahelix">Shigeru Chiba, Gregor Kiczales and John Lamping, ''[http://www2.parc.com/csl/groups/sda/publications/papers/Chiba-ISOTAS96/for-web.pdf Avoiding Confusion in Metacircularity: The Meta-Helix]'' in Proceedings of the Second JSSST International Symposium on Object Technologies for Advanced Software, [[Kanazawa, Ishikawa|Kanazawa]], Springer-Verlag LNCS 1049, pp 157-172, 1996</ref> which has been ported to many Scheme implementations.


A good example of a compile-time MOP is [[OpenC Plus Plus|OpenC++]].
A good example of a compile-time MOP is [[OpenC++]].


=== Usage ===
=== Usage ===

Revision as of 04:51, 10 September 2010

In computer science, a metaobject or meta-object is any entity that manipulates, creates, describes, or implements other objects. The object that the metaobject is about is called the base object. Some information that a metaobject might store is the base object's type, interface, class, methods, attributes, variables, functions, control structures, etc.

Metaobject protocol

A metaobject protocol (MOP) is an interpreter of the semantics of a program that is open and extensible. Therefore, a MOP determines what a program means and what its behavior is, and it is extensible in that a programmer (or metaprogrammer) can alter program behavior by extending parts of the MOP. The MOP exposes some or all internal structure of the interpreter to the programmer. The MOP may manifest as a set of classes and methods that allow a program to inspect the state of the supporting system and alter its behaviour. MOPs are implemented as object-oriented programs where all objects are metaobjects.

Runtime and compile time

MOPs may be runtime or compile time. The metaobjects of runtime MOPs exist while a program is running, or executing. Instead, the metaobjects of compile-time MOPs exist only while a program is compiled. They may alter or extend the compiling process, but do not exist when the program is running.

One of the best-known runtime MOPs is the one described in the book The Art of the Metaobject Protocol (often referred to as AMOP); it applies to the Common Lisp Object System (CLOS) and allows the mechanisms of inheritance, method dispatching, class instantiation and so on to be manipulated. At Xerox PARC, one of the authors of AMOP, Gregor Kiczales, developed a small but powerful MOP-based runtime object system in Scheme called TinyCLOS.[1] which has been ported to many Scheme implementations.

A good example of a compile-time MOP is OpenC++.

Usage

One example use of a MOP is to alter the implementation of multiple inheritance. A recurring issue is how to resolve conflicting slots and methods of the superclasses. Typically, language designers select one solution, and language users must live with it. Instead, a metaobject protocol makes it possible to change the rules of inheritance and choose a different solution for individual classes.

A metaobject protocol is one way to implement aspect-oriented programming languages. Many of the early founders of MOPs, including Gregor Kiczales have since moved on to be the primary advocates for aspect-oriented programming.

See also

References

  1. ^ Shigeru Chiba, Gregor Kiczales and John Lamping, Avoiding Confusion in Metacircularity: The Meta-Helix in Proceedings of the Second JSSST International Symposium on Object Technologies for Advanced Software, Kanazawa, Springer-Verlag LNCS 1049, pp 157-172, 1996
Retrieved from "https://en.wikipedia.org/w/index.php?title=Metaobject&oldid=383967604"