 | This article has multiple issues. Please helpimprove it or discuss these issues on thetalk page.(Learn how and when to remove these messages) (Learn how and when to remove this message)
|
Inobject-oriented programming, ametaclass is aclass whosesyntactic definitions are used for the syntactic definition of the classes themselves. Unlike ordinary classes, which define the behaviors of objects, metaclasses specify the behaviors of classes and their instances. Not all object-orientedprogramming 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 asfirst-class citizens, making a metaclass an object that creates and manages these classes. Each programming language adheres to its ownmetaobject protocol, which are the rules that determine interactions among objects, classes, and metaclasses.[1] Metaclasses are utilized to automate code generation and to enhance framework development.[2]
InPython, the builtin classtype is a metaclass.[3][4][5] Consider this simple Python class:
classCar:make:strmodel:stryear:intcolor:strdef__init__(self,make:str,model:str,year:int,color:str)->None:self.make=makeself.model=modelself.year=yearself.color=color@propertydefdescription(self)->str:""" Return a description of this car. """returnf"{self.color}{self.make}{self.model}"
At run time,Car itself is an instance oftype. The source code of theCar class, shown above, does not include such details as the size in bytes ofCar objects, their binary layout in memory, how they are allocated, that the__init__ method is automatically called each time aCar is created, and so on. These details come into play not only when a newCar object is created, but also each time any attribute of aCar is accessed. In languages without metaclasses, these details are defined by the language specification and can't be overridden. In Python, the metaclass -type - controls these details ofCar's behavior. They can be overridden by using a different metaclass instead oftype.
The above example contains some redundant code to do with the four attributesmake,model,year, andcolor. It is possible to eliminate some of this redundancy using a custom metaclass. In Python, a metaclass is most easily defined as a subclass oftype.
fromtypingimportAnyclassAttributeInitType(type):def__call__(self,*args:tuple[Any],**kwargs:dict[str,Any])->object:""" Create a new instance. """# First, create the object in the normal default way.obj:object=type.__call__(self,*args)# Additionally, set attributes on the new object.forname,valueinkwargs.items():setattr(obj,name,value)# Return the new object.returnobj
This metaclass only overrides object creation. All other aspects of class and object behavior are still handled bytype.
Now the classCar can be rewritten to use this metaclass. In Python 3 this is done by providing a "keyword argument"metaclass to the class definition:
classCar(object,metaclass=AttributeInitType):@propertydefdescription(self)->str:""" Return a description of this car. """return" ".join(str(value)forvalueinself.__dict__.values())
The resulting objectCar can be instantiated as usual, but can contain any number of keyword arguments:
new_car:Car=Car(make='Toyota',model='Prius',year=2005,color='Green',engine='Hybrid')
 | This sectiondoes notcite anysources. Please helpimprove this section byadding citations to reliable sources. Unsourced material may be challenged andremoved.(October 2013) (Learn how and when to remove this message) |
InSmalltalk, everything is anobject. Additionally, Smalltalk is aclass 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 objectc is an instance of the classCar. In turn, the classCar is again an object and as such an instance of the metaclass ofCar calledCar class. 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 evaluatingCar class results in the metaclass object forCar whose name isCar class (one can confirm this by evaluatingCar class name which returns the name of the metaclass ofCar.)
Class methods actually belong to the metaclass, just as instance methods actually belong to the class. When a message is sent to the object2, the search for the method starts inInteger. 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 toInteger the search for the method starts inInteger class and proceeds up the superclass chain toObject class. Note that, so far, the metaclass inheritance chain exactly follows that of the class inheritance chain. But the metaclass chain extends further becauseObject class is the subclass ofClass. All metaclasses are subclasses of Class.
In early Smalltalks, there was only one metaclass calledClass. This implied that themethods all classes have were the same, in particular the method to create new objects, i.e.,new. To allow classes to have their own methods and their own instance variables (called class instance variables and should not be confused withclass variables), Smalltalk-80 introduced for each classC their own metaclassC class. This means that each metaclass is effectively asingleton class.
Since there is no requirement that metaclasses behave differently from each other, all metaclasses are instances of only one class calledMetaclass. The metaclass ofMetaclass is calledMetaclass class which again is an instance of classMetaclass.
In Smalltalk-80, every class (exceptObject) has asuperclass. Theabstract superclass of all metaclasses isClass, which describes the general nature of classes.
The superclass hierarchy for metaclasses parallels that for classes, except for classObject. ALL metaclasses are subclasses ofClass, therefore:
Object class superclass == Class.Likeconjoined twins, classes and metaclasses are born together.Metaclass has an instance variablethisClass, which points to its conjoined class.Note that the usual Smalltalkclass 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:
Object is the base class that provides common methods for all objects; "an object" is an integer, or a widget, or aCar, etc.Class is the base of the metaclasses that provides common methods for all classes (though it is not a metaclass itself); "a class" is something likeInteger, orWidget, orCar, etc.Metaclass provides common methods for all metaclasses.Four classes provide the facilities to describe new classes. Theirinheritance hierarchy (from Object), and the main facilities they provide are:
Ruby purifies the Smalltalk-80 concept of metaclasses by introducingeigenclasses,removing theMetaclass class,and (un)redefining the class-of map.The change can be schematized as follows:[6]
| → |
|
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 objectx has its own meta-object, called theeigenclass ofx, which is one meta-level higher thanx. The "higher order" eigenclasses usually exist purely conceptually – they do not contain any methods or store any (other) data in most Ruby programs.[7]
The following diagrams show a sample core structure of Smalltalk-80 and Ruby in comparison.[8]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: classesA andBand terminal objectsu andv.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 fromx points to the least actual container ofx that is the start point for the method lookup when a method is invoked onx). Gray nodes display the eigenclasses (resp. implicit metaclasses in the case of Smalltalk-80).
| Smalltalk-80 | Ruby | |
 |  |
The diagram on the right also provides a picture oflazy evaluation of eigenclasses in Ruby. Thev object can have its eigenclass evaluated (allocated) as a consequence of addingsingleton methods tov.
According to the Ruby's introspection method namedclass,the class of every class (and of every eigenclass) isconstantly theClass class (denoted byc in the diagram).Class, andStruct are the only classes that have classes as instances.[9][disputed –discuss] Subclassing ofClass is disallowed.Following the standard definition of metaclasses we can conclude thatClass andStruct 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 betweentheclass introspection method in Ruby and Smalltalk. While the mapx ↦ x.class coincides on terminal objects, it differs in the restriction to classes. As already mentioned above, for a classx, the Ruby expressionx.class evaluates constantly toClass. In Smalltalk-80, ifx is a class then the expressionx class correspondsto the Ruby'sx.singleton_class– which evaluates to the eigenclass ofx.
| This sectionneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources in this section. Unsourced material may be challenged and removed.(October 2013) (Learn how and when to remove this message) |
 | This section'stone or style may not reflect theencyclopedic tone used on Wikipedia. See Wikipedia'sguide to writing better articles for suggestions.(September 2013) (Learn how and when to remove this message) |
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 functionsobjc_allocateClassPair() andobjc_registerClassPair() 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 typeClass (similar to the typeid 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 (usuallyNSObject using theCocoa 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.[10]
Herb Sutter of the ISO C++ Committee, has proposed the inclusion of metaclasses to C++ (originally forC++20 usingC++17 features), though this feature has still not been included.[11]
This feature would build off ofC++ concepts (constraints on types andtemplates),reflection, andif constexpr. Its primary goal would be to expand C++ abstraction beyond defined vocabulary (class,struct,union,enum, etc.) to allow adoptable vocabulary (such asinterface,value), for the purpose of a more liberal approach to programming free of rule-memorisation. This feature would also allow non-standard features (such asinterfaces) to be expressed as core features within libraries, and eliminate the necessity of specialised compilers (such asQt moc,C++/CX, etc.) to express specific information using standardised features.
AlthoughC++26 adopted different means to represent reflection,[12] the paper proposed$T to represent reflecting typeT and$expr to represent reflecting an expressionexpr, based off of an older proposal for reflection.[13] For example, this would examine each member variablem inT for one namedxyzzy, and inject anint namedplugh, using aconstexpr block with-> {} (for injecting code into the enclosing scope). It further proposed compiler-integrated diagnostics to emit compiler diagnostic messages (i.e.compiler.error("Some error",source_location)). Named concepts could be used to declare symbols, similar to assigning concrete classes to variables holding interface types inJava andC#.[14]
usingstd::meta::variable;constexpr{for(variablem:$T.variables()){if(m.name()=="xyzzy")->{intplugh;}}}
For example, the following would create a metaclass calledinterface which would behave similar to aJava interface:
usingstd::meta::function;$classinterface{~interface()noexcept{// custom logic if necessary here...}constexpr{compiler.require($interface.variables().empty(),"interfaces may not contain data");for(functionf:$interface.functions()){compiler.require(!f.is_copy()&&!f.is_move(),"Interfaces may not copy or move; consider a virtual clone instead");if(!f.has_access()){f.make_public();}compiler.require(f.is_public(),"Interface functions must be public");f.make_pure_virtual();}}};// now supports (similar to Java/C#):interfaceShape{intarea()const;voidscaleBy(doublefactor);};
One could similarly emulateProject Valhalla Java value classes, by creating$class value which generates comparison operators and default constructors.
It would further support ad-hocduck typing:
$T.is(M) evaluates totrue if and only if applyingM toT succeeds (i.e.T already definesM) and its resulting type has no new members not already present inT.$T.as(M) generates a type identical toT but is additionally defined using the named metaclassM.It would allow for "strongertypedefs": types that behave similar to the original type but are distinct types for overloading and cannot implicitly convert to/from the original type by default:
$classnoop{};// a no-op metaclass// equivalent to: enum class Handle: int { ... };usingHandle=$int.as(noop);
The following list (but not limited to) metaclasses were proposed to be defined in the standard library:
interface: an abstract base class with all public virtual functions, no copy/move constructors or data membersbase_class: a class designed to be inherited from with no copy/move constructors or data membersordered et al., classes which support some comparison category (such as total ordering, equality comparison, etc.)value, a value class with default constructor/destructor, copy/move constructors, comparison methods, and no virtual methods or protected membersplain_struct, sometimes called "plain old data structs" (similar to "Plain old Java objects")flag_enum, an enum for representing flags storing values corresponding to bitwiseOR enumeratorsThe paper proposes that this allows for abstractions to greatly decrease boilerplate by producing generated functions and customisable defaults, semantics, and constraints. It further abolishes the need to create new language feature proposals by allowing such features to be expressed using metaclass features.
The following are some of the most prominentprogramming languages that support metaclasses.
Some less widespread languages that support metaclasses includeOpenJava,OpenC++,OpenAda,CorbaScript,ObjVLisp,Object-Z,MODEL-K,XOTcl, andMELDC. Several of these languages date from the early 1990s and are of academic interest.[15]
Java featuresjava.lang.Class<T> forintrospection, similar to metaclasses, but are not actually metaclasses.
Logtalk, an object-oriented extension ofProlog, also supports metaclasses.
Resource Description Framework (RDF) andUnified Modeling Language (UML) both support metaclasses.
Metaclasses were a proposed for a possible inclusion in future version ofC++, but currently is not an included feature.[11]