Metaclass

Last updated

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 citizens, 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. [1]

Contents

Python example

In Python, the builtin class type is a metaclass. [2] [3] [4] Consider this simple Python class:

classCar:def__init__(self,make:str,model:str,year:int,color:str)->None:self.make=makeself.model=modelself.year=yearself.color=color@propertydefdescription(self):"""Return a description of this car."""returnf"{self.color}{self.year}{self.make}{self.model}"

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.

classAttributeInitType(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.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 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:

classCar(object,metaclass=AttributeInitType):@propertydefdescription(self):"""Return a description of this car."""return" ".join(str(value)forvalueinself.__dict__.values())

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

new_car=Car(make='Toyota',model='Prius',year=2005,color='Green',engine='Hybrid')

In Smalltalk-80

The Smalltalk-80 metaclass hierarchy as a UML diagram Smalltalk 80 metaclasses.svg
The Smalltalk-80 metaclass hierarchy as a UML diagram
Diagram of the inheritance and instance relationships between classes and metaclasses in Smalltalk Smalltalk metaclass.png
Diagram of the inheritance and instance relationships between classes and metaclasses in Smalltalk

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 (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 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 (one can confirm this by evaluating Car class name which returns the name of the metaclass of Car.)

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 (called class instance variables and should not be confused with class 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 (except Object) 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 (from Object), and the main facilities they provide are:

Object - default behavior common to all objects, like class access
Behavior - minimum 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 eigenclasses, removing the Metaclass class, and (un)redefining the class-of map. The change can be schematized as follows: [5]

Smalltalk-80
Classes
Implicit
metaclasses
  
Terminal
objects
Ruby
Classes
Eigenclasses of
classes
Eigenclasses
of
eigenclasses
Terminal
objects
Eigenclasses of
terminal objects

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. [6]

The following diagrams show a sample core structure of Smalltalk-80 and Ruby in comparison. [7] 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 A and B and terminal objects u and v. 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).

Smalltalk-80 Ruby
Smalltalk-metaclass-sample.svg Ruby-metaclass-sample.svg

The diagram on the right also provides a picture of lazy evaluation of eigenclasses in Ruby. The v object can have its eigenclass evaluated (allocated) as a consequence of adding singleton methods to v.

According to the Ruby's introspection method named class, the class of every class (and of every eigenclass) is constantly the Class class (denoted by c in the diagram). Class, and Struct are the only classes that have classes as instances. [8] [ disputed ] 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

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. Objective-C metaclass.png
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 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 (similar to the type id 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 NSObject using the 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. [9]

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. [11]

Logtalk, an object-oriented extension of Prolog, also supports metaclasses.

Resource Description Framework (RDF) and Unified Modeling Language (UML) both support metaclasses.

See also

Related Research Articles

In object-oriented programming, a class is an extensible program-code-template for creating objects, providing initial values for state and implementations of behavior. In many languages, the class name is used as the name for the class, the name for the default constructor of the class, and as the type of objects generated by instantiating the class; these distinct concepts are easily conflated. Although, to the point of conflation, one could argue that is a feature inherent in a language because of its polymorphic nature and why these languages are so powerful, dynamic and adaptable for use compared to languages without polymorphism present. Thus they can model dynamic systems more easily.

Multiple inheritance is a feature of some object-oriented computer programming languages in which an object or class can inherit characteristics and features from more than one parent object or parent class. It is distinct from single inheritance, where an object or class may only inherit from one particular object or class.

Smalltalk Object-oriented programming language first released in 1972

Smalltalk is an object-oriented, dynamically typed reflective programming language. Smalltalk was created as the language underpinning the "new world" of computing exemplified by "human–computer symbiosis". It was designed and created in part for educational use, specifically for constructionist learning, at the Learning Research Group (LRG) of Xerox PARC by Alan Kay, Dan Ingalls, Adele Goldberg, Ted Kaehler, Diana Merry, Scott Wallace, and others during the 1970s.

Common Lisp Object System

The Common Lisp Object System (CLOS) is the facility for object-oriented programming which is part of ANSI Common Lisp. CLOS is a powerful dynamic object system which differs radically from the OOP facilities found in more static languages such as C++ or Java. CLOS was inspired by earlier Lisp object systems such as MIT Flavors and CommonLoops, although it is more general than either. Originally proposed as an add-on, CLOS was adopted as part of the ANSI standard for Common Lisp and has been adapted into other Lisp dialects such as EuLisp or Emacs Lisp.

In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created. This is in contrast to a mutable object, which can be modified after it is created. In some cases, an object is considered immutable even if some internally used attributes change, but the object's state appears unchanging from an external point of view. For example, an object that uses memoization to cache the results of expensive computations could still be considered an immutable object.

In computer science, reflective programming or reflection is the ability of a process to examine, introspect, and modify its own structure and behavior.

In computing, type introspection is the ability of a program to examine the type or properties of an object at runtime. Some programming languages possess this capability.

In class-based object-oriented programming, a constructor is a special type of subroutine called to create an object. It prepares the new object for use, often accepting arguments that the constructor uses to set required member variables.

Method overriding

Method overriding, in object-oriented programming, is a language feature that allows a subclass or child class to provide a specific implementation of a method that is already provided by one of its superclasses or parent classes. The implementation in the subclass overrides (replaces) the implementation in the superclass by providing a method that has same name, same parameters or signature, and same return type as the method in the parent class. The version of a method that is executed will be determined by the object that is used to invoke it. If an object of a parent class is used to invoke the method, then the version in the parent class will be executed, but if an object of the subclass is used to invoke the method, then the version in the child class will be executed. Some languages allow a programmer to prevent a method from being overridden.

ObjVlisp is a 1984 object-oriented extension of Vlisp–Vincennes LISP, a LISP dialect developed since 1971 at the University of Paris VIII – Vincennes. It is noteworthy as one of the earliest implementations of the concept of metaclasses, and in particular explicit metaclasses. In the ObjVlisp model, "each entity is an instance of a single class. Classes are instances of other classes, called metaclasses. This model allows for extension of the static part of OOL, i.e. the structural aspects of objects considered as implementation of abstract data types"

The uniform access principle of computer programming was put forth by Bertrand Meyer. It states "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation". This principle applies generally to the syntax of object-oriented programming languages. In simpler form, it states that there should be no syntactical difference between working with an attribute, pre-computed property, or method/query of an object.

In object-oriented programming, inheritance is the mechanism of basing an object or class upon another object or class, retaining similar implementation. Also defined as deriving new classes from existing ones such as super class or base class and then forming them into a hierarchy of classes. In most class-based object-oriented languages, an object created through inheritance, a "child object", acquires all the properties and behaviors of the "parent object", with the exception of: constructors, destructor, overloaded operators and friend functions of the base class. Inheritance allows programmers to create classes that are built upon existing classes, to specify a new implementation while maintaining the same behaviors, to reuse code and to independently extend original software via public classes and interfaces. The relationships of objects or classes through inheritance give rise to a directed graph.

PyObjC is a bidirectional bridge between the Python and Objective-C programming languages, allowing programmers to use and extend existing Objective-C libraries, such as Apple's Cocoa framework, using Python.

this, self, and Me are keywords used in some computer programming languages to refer to the object, class, or other entity of which the currently running code is a part. The entity referred to by these keywords thus depends on the execution context. Different programming languages use these keywords in slightly different ways. In languages where a keyword like "this" is mandatory, the keyword is the only way to access data and methods stored in the current object. Where optional, they can disambiguate variables and functions with the same name.

The syntax of the Python programming language is the set of rules that defines how a Python program will be written and interpreted. The Python language has many similarities to Perl, C, and Java. However, there are some definite differences between the languages.

A property, in some object-oriented programming languages, is a special sort of class member, intermediate in functionality between a field and a method. The syntax for reading and writing of properties is like for fields, but property reads and writes are (usually) translated to 'getter' and 'setter' method calls. The field-like syntax is easier to read and write than many method calls, yet the interposition of method calls "under the hood" allows for data validation, active updating, or implementation of what may be called "read-only fields".

This comparison of programming languages compares how object-oriented programming languages such as C++, Java, Smalltalk, Object Pascal, Perl, Python, and others manipulate data structures.

Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code: data in the form of fields, and code, in the form of procedures.

Objective-C is a general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language. It was the main programming language supported by Apple for macOS, iOS, and their respective application programming interfaces (APIs), Cocoa and Cocoa Touch, until the introduction of Swift in 2014.

References

  1. Ira R. Forman and Scott Danforth (1999). Putting Metaclasses to Work. ISBN   0-201-43305-2.
  2. IBM Metaclass programming in Python, parts 1 Archived 2008-09-03 at the Wayback Machine , 2 and 3
  3. Artima Forum: Metaclasses in Python 3.0 (part 1 of 2) (part 2 of 2)
  4. David Mertz. "A Primer on Python Metaclass Programming". ONLamp . Archived from the original on April 30, 2003. Retrieved June 28, 2006.
  5. "The Ruby Object Model: Comparison with Smalltalk-80".
  6. Paolo Perrotta (2010). Metaprogramming Ruby. Pragmatic Bookshelf. ISBN   978-1-934356-47-0.
  7. "Object Membership: The Core Structure of Object Technology".
  8. "Struct". Ruby Doc. Retrieved 1 May 2015.
  9. Cocoa with Love: What is a meta-class in Objective-C?
  10. Herb Sutter. "Metaclasses" (PDF).
  11. "An implementation of mixins in Java using metaclasses" (PDF). Archived from the original (PDF) on 2007-10-16. Retrieved 2007-11-27.