Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Metaclass
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{Short description|A metaclass describes commen behaviour for classes, like a class does for objects}} {{multiple issues| {{original research|date=September 2013}} {{more citations needed|date=September 2013}} }} In [[object-oriented programming]], a '''metaclass''' is a [[Class (computer science)|class]] whose [[Instance (computer programming)|instances]] are classes themselves. Unlike ordinary classes, which define the behaviors of objects, metaclasses specify the behaviors of classes and their instances. Not all object-oriented [[programming languages]] support the concept of metaclasses. For those that do, the extent of control metaclasses have over class behaviors varies. Metaclasses are often implemented by treating classes as [[first-class citizen|first-class citizens]], making a metaclass an object that creates and manages these classes. Each programming language adheres to its own [[metaobject protocol]], which are the rules that determine interactions among objects, classes, and metaclasses.<ref>{{cite book|author=Ira R. Forman and Scott Danforth|title=Putting Metaclasses to Work|year=1999|publisher=Addison-Wesley |isbn=0-201-43305-2}}</ref> Metaclasses are utilized to automate code generation and to enhance framework development.<ref>{{cite book |last1=AloorRavi |first1=Sulekha |title=Metaprogramming with Python |date=2022 |publisher=Packt Publishing |location=Birmingham}}</ref> ==Python example== In [[Python (programming language)|Python]], the builtin class <code>type</code> is a metaclass.<ref>IBM Metaclass programming in Python, parts [http://www.ibm.com/developerworks/linux/library/l-pymeta.html 1] {{webarchive|url=https://web.archive.org/web/20080903123731/http://www.ibm.com/developerworks/linux/library/l-pymeta.html |date=2008-09-03 }}, [http://www-128.ibm.com/developerworks/linux/library/l-pymeta2/ 2] and [http://www.ibm.com/developerworks/library/l-pymeta3.html 3]</ref><ref>Artima Forum: Metaclasses in Python 3.0 [http://www.artima.com/forums/flat.jsp?forum=106&thread=236234 (part 1 of 2)] [http://www.artima.com/forums/flat.jsp?forum=106&thread=236260 (part 2 of 2)]</ref><ref>{{cite web | url=http://www.onlamp.com/lpt/a/3388 | title=A Primer on Python Metaclass Programming | author=David Mertz | work=[[O'Reilly Media|ONLamp]] | accessdate=June 28, 2006 | url-status=dead | archiveurl=https://web.archive.org/web/20030430162409/http://www.onlamp.com/lpt/a/3388 | archivedate=April 30, 2003 }}</ref> Consider this simple Python class: <syntaxhighlight lang="python"> class Car: def __init__(self, make: str, model: str, year: int, color: str): self.make = make self.model = model self.year = year self.color = color @property def description(self) -> str: """Return a description of this car.""" return f"{self.color} {self.make} {self.model}" </syntaxhighlight> At run time, <code>Car</code> itself is an instance of <code>type</code>. The source code of the <code>Car</code> class, shown above, does not include such details as the size in bytes of <code>Car</code> objects, their binary layout in memory, how they are allocated, that the <code>__init__</code> method is automatically called each time a <code>Car</code> is created, and so on. These details come into play not only when a new <code>Car</code> object is created, but also each time any attribute of a <code>Car</code> is accessed. In languages without metaclasses, these details are defined by the language specification and can't be overridden. In Python, the metaclass - <code>type</code> - controls these details of <code>Car</code>'s behavior. They can be overridden by using a different metaclass instead of <code>type</code>. The above example contains some redundant code to do with the four attributes <code>make</code>, <code>model</code>, <code>year</code>, and <code>color</code>. It is possible to eliminate some of this redundancy using a custom metaclass. In Python, a metaclass is most easily defined as a subclass of <code>type</code>. <syntaxhighlight lang="python"> class AttributeInitType(type): def __call__(self, *args, **kwargs): """Create a new instance.""" # First, create the object in the normal default way. obj = type.__call__(self, *args) # Additionally, set attributes on the new object. for name, value in kwargs.items(): setattr(obj, name, value) # Return the new object. return obj </syntaxhighlight> This metaclass only overrides object creation. All other aspects of class and object behavior are still handled by <code>type</code>. Now the class <code>Car</code> can be rewritten to use this metaclass. In Python 3 this is done by providing a "keyword argument" <code>metaclass</code> to the class definition: <syntaxhighlight lang="python"> class Car(object, metaclass=AttributeInitType): @property def description(self) -> str: """Return a description of this car.""" return " ".join(str(value) for value in self.__dict__.values()) </syntaxhighlight> The resulting object <code>Car</code> can be instantiated as usual, but can contain any number of keyword arguments: <syntaxhighlight lang="python"> new_car = Car(make='Toyota', model='Prius', year=2005, color='Green', engine='Hybrid') </syntaxhighlight> ==In Smalltalk-80== {{unreferenced section|date=October 2013}} [[File:Smalltalk 80 metaclasses.svg|thumb|The Smalltalk-80 metaclass hierarchy as a UML diagram]] [[File:Smalltalk metaclass.png|thumb|Diagram of the inheritance and instance relationships between classes and metaclasses in Smalltalk]] In [[Smalltalk]], everything is an [[Object (computer science)|object]]. Additionally, Smalltalk is a [[Class-based programming|class based]] system, which means that every object has a class that defines the structure of that object (i.e. the instance variables the object has) and the messages an object understands. Together this implies that a class in Smalltalk is an object and that, therefore a class needs to be an instance of a class (called metaclass). As an example, a car object <code>c</code> is an instance of the class <code>Car</code>. In turn, the class <code>Car</code> is again an object and as such an instance of the metaclass of <code>Car</code> called <code>Car class</code>. Note the blank in the name of the metaclass. The name of the metaclass is the Smalltalk expression that, when evaluated, results in the metaclass object. Thus evaluating <code>Car class</code> results in the metaclass object for <code>Car</code> whose name is <code>Car class</code> (one can confirm this by evaluating <code>Car class name</code> which returns the name of the metaclass of <code>Car</code>.) [[Class method]]s actually belong to the metaclass, just as instance methods actually belong to the class. When a message is sent to the object <code>2</code>, the search for the method starts in <code>Integer</code>. If it is not found it proceeds up the superclass chain, stopping at Object whether it is found or not. When a message is sent to <code>Integer</code> the search for the method starts in <code>Integer class</code> and proceeds up the superclass chain to <code>Object class</code>. Note that, so far, the metaclass inheritance chain exactly follows that of the class inheritance chain. But the metaclass chain extends further because <code>Object class</code> is the subclass of <code>Class</code>. All metaclasses are subclasses of Class. In early Smalltalks, there was only one metaclass called <code>Class</code>. This implied that the [[method (computer science)|methods]] all classes have were the same, in particular the method to create new objects, i.e., <code>new</code>. To allow classes to have their own methods and their own instance variables (called class instance variables and should not be confused with [[class variable]]s), Smalltalk-80 introduced for each class <code>C</code> their own metaclass <code>C class</code>. This means that each metaclass is effectively a [[Singleton pattern|singleton]] class. Since there is no requirement that metaclasses behave differently from each other, all metaclasses are instances of only one class called <code>Metaclass</code>. The metaclass of <code>Metaclass</code> is called <code>Metaclass class</code> which again is an instance of class <code>Metaclass</code>. In Smalltalk-80, every class (except <code>Object</code>) has a [[superclass (computer science)|superclass]]. The [[abstract superclass]] of all metaclasses is <code>Class</code>, which describes the general nature of classes. The superclass hierarchy for metaclasses parallels that for classes, except for class <code>Object</code>. ALL metaclasses are subclasses of <code>Class</code>, therefore: * <code>Object class superclass == Class.</code> Like [[conjoined twins]], classes and metaclasses are born together. <code>Metaclass</code> has an instance variable <code>thisClass</code>, which points to its conjoined class. Note that the usual Smalltalk [[class browser]] does not show metaclasses as separate classes. Instead the class browser allows to edit the class together with its metaclass at the same time. The names of classes in the metaclass hierarchy are easily confused with the concepts of the same name. For instance: * <code>Object</code> is the base class that provides common methods for all objects; "an object" is an integer, or a widget, or a <code>Car</code>, etc. * <code>Class</code> is the base of the metaclasses that provides common methods for all classes (though it is not a metaclass itself); "a class" is something like <code>Integer</code>, or <code>Widget</code>, or <code>Car</code>, etc. * <code>Metaclass</code> provides common methods for all metaclasses. Four classes provide the facilities to describe new classes. Their [[inheritance hierarchy]] (from Object), and the main facilities they provide are: :Object - default behavior common to all objects, like class access ::Behavior - minimum [[State (computer science)|state]] for [[compiling]] methods and creating/running objects :::ClassDescription ([[abstract class]]) - class/variable naming, comments ::::Class - similar, more comprehensive, facilities to superclasses ::::Metaclass - initializing class variables, instance creation messages ==In Ruby== Ruby purifies the Smalltalk-80 concept of metaclasses by introducing [[wiktionary:eigenclasses|eigenclasses]], removing the <code>Metaclass</code> class, and (un)redefining the class-of map. <!-- --> The change can be schematized as follows:<ref>{{cite web | url=http://www.atalon.cz/rb-om/ruby-object-model/co-smalltalk/ | title=The Ruby Object Model: Comparison with Smalltalk-80 }}</ref> {| border=0 cellpadding=0 style="margin: 2ex auto" |- | {| class="wikitable" |+ Smalltalk-80 |- | <div style="height: 5ex; margin:1ex; padding: 1ex; border: 1px dotted gray;"><span style="position:relative; top:1ex;">Classes</span></div> | <div style="height: 5ex; margin:1ex; padding: 1ex 0.4ex; border: 1px dotted gray;"><span style="font-size:85%;">'''Implicit<br>metaclasses'''</span></div> | rowspan="2" style="width:4ex;" | |- | <div style="height: 5ex; margin:1ex; padding: 1ex; border: 1px dotted gray;">Terminal<br>objects</div> | |} | style="font-size: 200%; vertical-align: middle; padding: 1px 20px;" | → | {| class="wikitable" |+ Ruby |- | <div style="height: 5ex; margin:1ex; padding: 1ex; border: 1px dotted gray;"><span style="position:relative; top:1ex;">Classes</span></div> | <div style="height: 5ex; margin:1ex; padding: 1ex 0.4ex; border: 1px dotted gray;"><span style="font-size:85%;">'''Eigenclasses of<br>classes'''</span></div> | rowspan=2 | <div style="height: 12ex; margin:1ex; padding: 2ex 0.4ex; border: 1px dotted gray;"><span style="font-size:85%;">'''Eigenclasses<br>of<br>eigenclasses'''</span></div> |- | <div style="height: 5ex; margin:1ex; padding: 1ex; border: 1px dotted gray;">Terminal<br>objects</div> | <div style="height: 5ex; margin:1ex; padding: 1ex 0.4ex; border: 1px dotted gray;"><span style="font-size:85%;">'''Eigenclasses of<br>terminal objects'''</span></div> |} |} Note in particular the correspondence between Smalltalk's implicit metaclasses and Ruby's eigenclasses of classes. The Ruby eigenclass model makes the concept of implicit metaclasses fully uniform: every object ''x'' has its own meta-object, called the ''eigenclass'' of ''x'', which is one meta-level higher than ''x''. The "higher order" eigenclasses usually exist purely conceptually – they do not contain any methods or store any (other) data in most Ruby programs.<ref> {{cite book | publisher=Pragmatic Bookshelf | author=Paolo Perrotta | url=http://pragprog.com/book/ppmetr/metaprogramming-ruby | title=Metaprogramming Ruby | year=2010 | isbn=978-1-934356-47-0}}</ref> The following diagrams show a sample core structure of Smalltalk-80 and Ruby in comparison.<ref>{{cite web | url=http://www.atalon.cz/om/object-membership/ | title=Object Membership: The Core Structure of Object Technology }}</ref> In both languages, the structure consists of a built-in part which contains the circular objects (i.e. objects that appear in a cycle formed by a combination of blue or green links) and a user-part which has four explicit objects: classes <code>A</code> and <code>B</code> and terminal objects <code>u</code> and <code>v</code>. Green links show the child→parent relation of inheritance (with the implicit upward direction), blue links show the complementary member→container relation of instantiation (a blue link from ''x'' points to the least actual container of ''x'' that is the start point for the method lookup when a method is invoked on ''x''). Gray nodes display the eigenclasses (resp. implicit metaclasses in the case of Smalltalk-80). <!-- (<code>A</code> is a direct subclass of <code>Object</code>, <code>B</code> is a direct subclass of <code>A</code> and both <code>u</code> and <code>v</code> are direct instances of <code>B</code>). --> {| border=0 cellpadding=0 cellspacing=0 style="margin: 2ex auto" |- | style="text-align:center" | Smalltalk-80|| style="width:4ex" | || style="text-align:center" |Ruby |- | [[File:Smalltalk-metaclass-sample.svg|300px|Implicit metaclasses in Smalltalk-80 - A sample structure]]|| ||[[File:Ruby-metaclass-sample.svg|500px|Eigenclasses in Ruby - A sample structure]] |} The diagram on the right also provides a picture of [[lazy evaluation]] of eigenclasses in Ruby. The <code>v</code> object can have its eigenclass evaluated (allocated) as a consequence of adding ''singleton methods'' to <code>v</code>. According to the Ruby's introspection method named <code>class</code>, the class of every class (and of every eigenclass) is constantly the <code>Class</code> class (denoted by <code>c</code> in the diagram). <code>Class</code>, and <code>Struct</code> are the only classes that have classes as instances.<ref>{{cite web|title=Struct|url=https://docs.ruby-lang.org/en/master/Struct.html}}</ref> {{Disputed inline|The_Struct_class_in_Ruby|date=May 2015}} Subclassing of <code>Class</code> is disallowed. <!-- --> Following the standard definition of metaclasses we can conclude that <code>Class</code> and <code>Struct</code> are the only metaclasses in Ruby. This seems to contradict the correspondence between Ruby and Smalltalk, since in Smalltalk-80, every class has its own metaclass. The discrepancy is based on the disagreement between the <code>class</code> introspection method in Ruby and Smalltalk. While the map ''x ↦ x.''<code>class</code> coincides on terminal objects, it differs in the restriction to classes. As already mentioned above, for a class <code>''x''</code>, the Ruby expression <code>''x''.class</code> evaluates constantly to <code>Class</code>. In Smalltalk-80, if <code>''x''</code> is a class then the expression <code>''x'' class</code> corresponds to the Ruby's <code>''x''.singleton_class</code> – which evaluates to the eigenclass of <code>''x''</code>. == In Objective-C == {{more citations needed section|date=October 2013}} {{tone|section|date=September 2013}} [[File:Objective-C metaclass.png|thumb|Diagram of the inheritance and instance relationships between classes and metaclasses in Objective-C. Note that Objective-C has multiple root classes; each root class would have a separate hierarchy. This diagram only shows the hierarchy for an example root class NSObject. Each other root class would have a similar hierarchy.]] Metaclasses in Objective-C are almost the same as those in Smalltalk-80—not surprising since Objective-C borrows a lot from Smalltalk. Like Smalltalk, in Objective-C, the instance variables and methods are defined by an object's class. A class is an object, hence it is an instance of a metaclass. Like Smalltalk, in Objective-C, class methods are simply methods called on the class object, hence a class's class methods must be defined as instance methods in its metaclass. Because different classes can have different sets of class methods, each class must have its own separate metaclass. Classes and metaclasses are always created as a pair: the runtime has functions <code>objc_allocateClassPair()</code> and <code>objc_registerClassPair()</code> to create and register class-metaclass pairs, respectively. There are no names for the metaclasses; however, a pointer to any class object can be referred to with the generic type <code>Class</code> (similar to the type <code>id</code> being used for a pointer to any object). Because class methods are inherited through inheritance, like Smalltalk, metaclasses must follow an inheritance scheme paralleling that of classes (e.g. if class A's parent class is class B, then A's metaclass's parent class is B's metaclass), except that of the root class. Unlike Smalltalk, the metaclass of the root class inherits from the root class (usually <code>NSObject</code> using the [[Cocoa (API)|Cocoa]] framework) itself. This ensures that all class objects are ultimately instances of the root class, so that you can use the instance methods of the root class, usually useful utility methods for objects, on class objects themselves. Since metaclass objects do not behave differently (you cannot add class methods for a metaclass, so metaclass objects all have the same methods), they are all instances of the same class—the metaclass of the root class (unlike Smalltalk). Thus, the metaclass of the root class is an instance of itself. The reason for this is that all metaclasses inherit from root class; hence, they must inherit the class methods of the root class.<ref>[http://cocoawithlove.com/2010/01/what-is-meta-class-in-objective-c.html Cocoa with Love: What is a meta-class in Objective-C?]</ref> ==Support in languages and tools== The following are some of the most prominent [[programming language]]s that support metaclasses. * [[Common Lisp]], via [[Common Lisp Object System|CLOS]] * [[Delphi (programming language)|Delphi]] and other versions of [[Object Pascal]] influenced by it * [[Groovy (programming language)|Groovy]] * [[Objective-C]] * [[Object REXX|ooRexx]] * [[Python (programming language)|Python]] * [[Perl]], via the metaclass pragma, as well as [[Moose (Perl)|Moose]] * [[Ruby (programming language)|Ruby]] * [[Smalltalk]] * [[C++]] (proposed for a possible inclusion in future version of the standard)<ref>{{cite web|url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf|title=Metaclasses|author=Herb Sutter|author-link=Herb Sutter}}</ref> <!-- Please do not re-add the following languages to this list without discussing it on the talk page: * Java * Ruby --> Some less widespread languages that support metaclasses include [[OpenJava]], [[OpenC++ (software tool)|OpenC++]], [[OpenAda]], [[CorbaScript]], [[ObjVLisp]], [[Object-Z]], [[MODEL-K]], [[XOTcl]], and [[MELDC]]. Several of these languages date from the early 1990s and are of academic interest.<ref>{{Cite web |url=http://csl.ensm-douai.fr/noury/uploads/1/nouryBouraqadi.Gpce03WorkshopOnRepls.pdf |title=An implementation of mixins in Java using metaclasses |access-date=2007-11-27 |archive-url=https://web.archive.org/web/20071016230949/http://csl.ensm-douai.fr/noury/uploads/1/nouryBouraqadi.Gpce03WorkshopOnRepls.pdf |archive-date=2007-10-16 |url-status=dead }}</ref> [[Logtalk]], an object-oriented extension of [[Prolog]], also supports metaclasses. [[Resource Description Framework]] (RDF) and [[Unified Modeling Language]] (UML) both support metaclasses. ==See also== {{div col}} * [[Metamodeling|Metamodel]] * [[Metaprogramming]] * [[Metaobject]] * [[Kind (type theory)]] * [[Reflection (computer science)|Reflection]] * [[Dynamism (computing)|Dynamism]] * [[Adapter pattern]] * [[Metaclass (Semantic Web)]] {{div col end}} ==References== {{Reflist}} ==External links== * [http://www.atalon.cz/om/what-is-a-metaclass/ What Is a Metaclass?] {{Data types}} {{Meta-prefix}} [[Category:Class (computer programming)]] [[Category:Articles with example Python (programming language) code]]
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)
Pages transcluded onto the current version of this page
(
help
)
:
Template:Ambox
(
edit
)
Template:Cite book
(
edit
)
Template:Cite web
(
edit
)
Template:DMCA
(
edit
)
Template:Data types
(
edit
)
Template:Disputed inline
(
edit
)
Template:Div col
(
edit
)
Template:Div col end
(
edit
)
Template:Meta-prefix
(
edit
)
Template:More citations needed section
(
edit
)
Template:Multiple issues
(
edit
)
Template:Reflist
(
edit
)
Template:Short description
(
edit
)
Template:Tone
(
edit
)
Template:Unreferenced
(
edit
)
Template:Unreferenced section
(
edit
)
Template:Webarchive
(
edit
)