Metaobject

In computer science, a metaobject is an object that manipulates, creates, describes, or implements objects (including itself). The object that the metaobject pertains to is called the base object. Some information that a metaobject might define includes the base object's type, interface, class, methods, attributes, parse tree, etc. Metaobjects are examples of the computer science concept of reflection, where a system has access (usually at run time) to its own internal structure. Reflection enables a system to essentially rewrite itself on the fly, to alter its own implementation as it executes.[1]

Metaobject protocol

A metaobject protocol (MOP) provides the vocabulary (protocol) to access and manipulate the structure and behaviour of systems of objects. Typical functions of a metaobject protocol include:[2]

  • Create or delete a new class
  • Create a new property or method
  • Cause a class to inherit from a different class ("change the class structure")
  • Generate or change the code defining the methods of a class

Metaobject protocol is contrary to Bertrand Meyer's open/closed principle, which holds that software object systems should be open for extension but closed for modification. This principle effectively draws a distinction between extending an object by adding to it, and modifying an object by redefining it, proposing that the former is a desirable quality ("objects should be extensible to meet the requirements of future use cases"), while the latter is undesirable ("objects should provide a stable interface not subject to summary revision"). Metaobject protocol, by contrast, transparently exposes the internal composition of objects and the entire object system in terms of the system itself. In practice, this means that programmers may use objects to redefine themselves, possibly in quite complex ways.

Furthermore, metaobject protocol is not merely an interface to an "underlying" implementation; rather, through metaobject protocol the object system is recursively implemented in terms of a meta-object system, which itself is theoretically implemented in terms of a meta-metaobject system, and so on until an arbitrary base case (a consistent state of the object system) is determined, with the protocol as such being the recursive functional relationship between these implementation levels.

Implementing object systems in such a way opens the possibility for radical discretionary redesign, providing deep flexibility but introducing possibly complex or difficult-to-understand metastability issues (for instance, the object system must not destructively update its own metaobject protocol - its internal self-representation - but the potential destructiveness of some updates is non-trivial to predict and may be hard to reason about), depending on the recursive depth to which the desired modifications are propagated.[3] For this reason, metaobject protocol, when present in a language, is usually used sparingly and for specialised purposes such as software that transforms other software or itself in sophisticated ways, for example in reverse engineering.[4]

Runtime and compile time

When compilation is not available at run-time there are additional complications for the implementation of metaobject protocol. For example, it is possible to change the type hierarchy with such a protocol but doing so may cause problems for code compiled with an alternative class model definition. Some environments have found innovative solutions for this, e.g., by handling metaobject issues at compile time. A good example of this is OpenC++.[5] The Semantic Web object-oriented model is more dynamic than most standard object systems, and is consistent with runtime metaobject protocols. For example, in the Semantic Web model classes are expected to change their relations to each other and there is a special inference engine known as a classifier that can validate and analyze evolving class models.[6]

Usage

The first metaobject protocol was in the Smalltalk object-oriented programming language developed at Xerox PARC. The Common Lisp Object System (CLOS) came later and was influenced by the Smalltalk protocol as well as by Brian C. Smith's original studies on 3-Lisp as an infinite tower of evaluators.[7] The CLOS model, unlike the Smalltalk model, allows a class to have more than one superclass; this raises additional complexity in issues such as resolving the lineage of the class hierarchy on some object instance. CLOS also allows for dynamic multimethod dispatch, which is handled via generic functions rather than message passing like in Smalltalk's single dispatch.[8] The most influential book describing the semantics and implementation of the metaobject protocol in Common Lisp is The Art of the Metaobject Protocol by Gregor Kiczales et al.[9]

Metaobject protocols are also extensively used in software engineering applications. In virtually all commercial CASE, re-engineering, and Integrated Development Environments there is some form of metaobject protocol to represent and manipulate the design artifacts.[10][11][12]

A metaobject protocol is one way to implement aspect-oriented programming. Many of the early founders of MOPs, including Gregor Kiczales, have since moved on to be the primary advocates for aspect-oriented programming. Kiczales et al. of PARC were hired to design AspectJ for Java, a language which does not possess a native metaobject protocol.

gollark: It's ARBITRARY C!
gollark: HOW?!
gollark: WHY(JIT) is capable of arbitrary IO.
gollark: Er, you'd need to sandbox it.
gollark: ```python#!/usr/bin/env python3import argparseimport subprocessimport randomimport stringparser = argparse.ArgumentParser(description="Compile a WHY program using WHYJIT.")parser.add_argument("input", help="File containing WHY source code")parser.add_argument("-o", "--output", help="Filename of the output executable to make", default="./a.why")parser.add_argument("-O", "--optimize", help="Optimization level", type=int, default="0")args = parser.parse_args()def randomword(length): letters = string.ascii_lowercase return ''.join(random.choice(letters) for i in range(length))def which(program): proc = subprocess.run(["which", program], stdout=subprocess.PIPE) if proc.returncode == 0: return proc.stdout.replace(b"\n", b"") else: return Nonedef find_C_compiler(): compilers = ["gcc", "clang", "tcc", "cc"] for compiler in compilers: path = which(compiler) if path != None: return pathdef build_output(code, mx): C_code = f"""#define QUITELONG long long intconst QUITELONG max = {mx};int main() {{ volatile QUITELONG i = 0; // disable some "optimizations" that RUIN OUR BEAUTIFUL CODE! while (i < max) {{ i++; }} {code}}} """ heredoc = randomword(100) devnull = "2>/dev/null" shell_script = f"""#!/bin/shTMP1=/tmp/ignore-meTMP2=/tmp/ignore-me-tooTMP3=/tmp/dont-look-here cat << {heredoc} > $TMP1{C_code}{heredoc}sed -e '1,/^exit \$?$/d' "$0" > $TMP3chmod +x $TMP3$TMP3 -x c -o $TMP2 $TMP1chmod +x $TMP2$TMP2exit $?""".encode("utf-8") with open(find_C_compiler(), "rb") as f: return shell_script + f.read()input = args.inputoutput = args.outputwith open(input, "r") as f: contents = f.read() looplen = max(1000, (2 ** -args.optimize) * 1000000000) code = build_output( contents, looplen ) with open(output, "wb") as out: out.write(code)```

See also

References
  1. Smith, Brian C (1982-01-01). "Procedural Reflection In Programming Languages". MIT Technical Report (MIT-LCS-TR-272). Archived from the original on 13 December 2015. Retrieved 16 December 2013.
  2. Foote, Brian; Ralph Johnson (1–6 October 1989). "Reflective Facilities in Smalltalk-80". Oopsla '89: 327–335. doi:10.1145/74877.74911. ISBN 0897913337. Retrieved 16 December 2013.
  3. The Art of the Metaobject Protocol, Appendix C — Living with Circularity
  4. Favre, Lilliana; Liliana Martinez; Claudia Pereira (2009). MDA-Based Reverse Engineering of Object Oriented Code. Springer. doi:10.1007/978-3-642-01862-6_21. ISBN 978-3-642-01861-9.
  5. Chiba, Shigeru (1995). "A Metaobject Protocol for C++". Oopsla '95: 285–299. doi:10.1145/217838.217868. ISBN 978-0897917032. Retrieved 27 December 2013.
  6. Knublauch, Holger; Oberle, Daniel; Tetlow, Phil; Wallace, Evan (2006-03-09). "A Semantic Web Primer for Object-Oriented Software Developers". W3C. Retrieved 2008-07-30.
  7. Daniel P. Friedman; Mitchell Wand (1988). "The mystery of the tower revealed". The mystery of the tower revealed: A non-reflective description of the reflective tower. pp. 298–307. doi:10.1145/319838.319871. ISBN 978-0897912006.
  8. "Integrating Object-Oriented and Functional Programming" (PDF). Retrieved 7 July 2016.
  9. Kiczales, Gregor; Jim des Rivieres; Daniel G. Bobrow (July 30, 1991). The Art of the Metaobject Protocol. The MIT Press. ISBN 978-0262610742.
  10. Johnson, Lewis; David R. Harris; Kevin M. Benner; Martin S. Feather (October 1992). "Aries: The Requirements/Specification Facet for KBSA". Rome Laboratory Final Technical Report. RL-TR-92-248.
  11. "The Origin of Refine" (PDF). www.metaware.fr. Metaware White Paper. Archived from the original (PDF) on 7 January 2014. Retrieved 6 January 2014.
  12. "OMG's MetaObject Facility". omg.org. Object Management Group. Retrieved 7 January 2014.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.