Metaclass


In object-oriented programming, a metaclass is a class whose instances are classes. Just as an ordinary class defines the behavior of certain objects, a metaclass defines the behavior of certain classes and their instances. Not all object-oriented programming languages support metaclasses. Among those that do, the extent to which metaclasses can override any given aspect of class behavior varies. Metaclasses can be implemented by having classes be first-class citizen, in which case a metaclass is simply an object that constructs classes. Each language has its own metaobject protocol, a set of rules that govern how objects, classes, and metaclasses interact.

Python example

In Python, the builtin class type is a metaclass. Consider this simple Python class:

class Car:
def __init__ -> None:
self.make = make
self.model = model
self.year = year
self.color = color
@property
def description:
"""Return a description of this car."""
return f" "

At run time, Car itself is an instance of type. The source code of the Car class, shown above, does not include such details as the size in bytes of Car objects, their binary layout in memory, how they are allocated, that the __init__ method is automatically called each time a Car is created, and so on. These details come into play not only when a new Car object is created, but also each time any attribute of a Car 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 of Car's behavior. They can be overridden by using a different metaclass instead of type.
The above example contains some redundant code to do with the four attributes make, model, year, and color. It is possible to eliminate some of this redundancy using a metaclass. In Python, a metaclass is most easily defined as a subclass of type.

class AttributeInitType:
def __call__:
"""Create a new instance."""
# First, create the object in the normal default way.
obj = type.__call__
# Additionally, set attributes on the new object.
for name, value in kwargs.items:
setattr
# Return the new object.
return obj

This metaclass only overrides object creation. All other aspects of class and object behavior are still handled by type.
Now the class Car can be rewritten to use this metaclass. In Python 3 this done by providing a "keyword argument" metaclass to the class definition:

class Car:
@property
def description:
"""Return a description of this car."""
return " ".join for value in self.__dict__.values)

The resulting object Car can be instantiated as usual, but can contain any number of keyword arguments:

new_car = Car

In Smalltalk-80

In Smalltalk, everything is an object. Additionally, Smalltalk is a class based system, which means that every object has a class that defines the structure of that object 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.
As an example, a car object c is an instance of the class Car. In turn, the class Car is again an object and as such an instance of the metaclass of Car called Car 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 evaluating Car class results in the metaclass object for Car whose name is Car class
Class methods actually belong to the metaclass, just as instance methods actually belong to the class. When a message is sent to the object 2, the search for the method starts in Integer. 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 Integer the search for the method starts in Integer class and proceeds up the superclass chain to Object class. Note that, so far, the metaclass inheritance chain exactly follows that of the class inheritance chain. But the metaclass chain extends further because Object class is the subclass of Class. All metaclasses are subclasses of Class.
In early Smalltalks, there was only one metaclass called Class. This implied that the methods 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, Smalltalk-80 introduced for each class C their own metaclass C class. This means that each metaclass is effectively a singleton class.
Since there is no requirement that metaclasses behave differently from each other, all metaclasses are instances of only one class called Metaclass. The metaclass of Metaclass is called Metaclass class which again is an instance of class Metaclass.
In Smalltalk-80, every class has a superclass. The abstract superclass of all metaclasses is Class, which describes the general nature of classes.
The superclass hierarchy for metaclasses parallels that for classes, except for class Object. ALL metaclasses are subclasses of Class, therefore:
Like conjoined twins, classes and metaclasses are born together. Metaclass has an instance variable thisClass, 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:
Four classes provide the facilities to describe new classes. Their inheritance hierarchy, and the main facilities they provide are:

In Ruby

Ruby purifies the Smalltalk-80 concept of metaclasses by introducing,
removing the Metaclass class,
and redefining the class-of map.
The change can be schematized as follows:

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 data in most Ruby programs.
The following diagrams show a sample core structure of Smalltalk-80 and Ruby in comparison.
In both languages, the structure consists of a built-in part which contains the circular objects and a user-part which has four explicit objects: classes A and B
and terminal objects u and v.
Green links show the child→parent relation of inheritance, blue links show the complementary member→container relation of instantiation. Gray nodes display the eigenclasses.
The diagram on the right also provides a picture of lazy evaluation of eigenclasses in Ruby. The v object can have its eigenclass evaluated as a consequence of adding singleton methods to v.
According to the Ruby's introspection method named class,
the class of every class is
constantly the Class class.
Class, and Struct are the only classes that have classes as instances. Subclassing of Class is disallowed.
Following the standard definition of metaclasses we can conclude that Class and Struct 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 class introspection method in Ruby and Smalltalk. While the map x ↦ x.class coincides on terminal objects, it differs in the restriction to classes. As already mentioned above, for a class x, the Ruby expression x.class evaluates constantly to Class. In Smalltalk-80, if x is a class then the expression x class corresponds
to the Ruby's x.singleton_class
– which evaluates to the eigenclass of x.

In Objective-C

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 objc_allocateClassPair and objc_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 type Class.
Because class methods are inherited through inheritance, like Smalltalk, metaclasses must follow an inheritance scheme paralleling that of classes, except that of the root class.
Unlike Smalltalk, the metaclass of the root class inherits from the root class 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, they are all instances of the same class—the metaclass of the root class. 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.

Support in languages and tools

The following are some of the most prominent programming languages that support metaclasses.
Some less widespread languages that support metaclasses include OpenJava, 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.
Logtalk, an object-oriented extension of Prolog, also supports metaclasses.
Resource Description Framework and Unified Modeling Language both support metaclasses.
OWIKI.org. Text is available under the Creative Commons Attribution-ShareAlike License.