15.4: The Metaclass Hierarchy Parallels the Class Hierarchy
- Page ID
- 39664
Rule 7 says that the superclass of a metaclass cannot be an arbitrary class: it is constrained to be the metaclass of the superclass of the metaclass’s unique instance.
SortedCollection class superclass >>> OrderedCollection class
SortedCollection superclass class >>> OrderedCollection class
This is what we mean by the metaclass hierarchy being parallel to the class hierarchy. Figure \(\PageIndex{1}\) shows how this works in the SortedCollection hierarchy.
SortedCollection class >>> SortedCollection class
SortedCollection class superclass >>> OrderedCollection class
SortedCollection class superclass superclass >>> SequenceableCollection class
SortedCollection class superclass superclass superclass superclass >>> Object class
Uniformity between Classes and Objects
It is interesting to step back a moment and realize that there is no difference between sending a message to an object and to a class. In both cases the search for the corresponding method starts in the class of the receiver, and proceeds up the inheritance chain.
Thus, messages sent to classes must follow the metaclass inheritance chain. Consider, for example, the method withAll:, which is implemented on the class side of Collection. When we send the message withAll: to the class OrderedCollection, then it is looked up the same way as any other message. The lookup starts in OrderedCollection class (since it starts in the class of the receiver and the receiver is OrderedCollection), and proceeds up the metaclass hierarchy until it is found in Collection class (see Figure \(\PageIndex{2}\)). It returns a new instance of OrderedCollection.
OrderedCollection withAll: #(4 5 6 1 2 3) >>> an OrderedCollection (4 5 6 1 2 3)
Only one method lookup
Thus we see that there is one uniform kind of method lookup in Pharo. Classes are just objects, and behave like any other objects. Classes have the power to create new instances only because classes happen to respond to the message new, and because the method for new knows how to create new instances.
Normally, non-class objects do not understand this message, but if you have a good reason to do so, there is nothing stopping you from adding a new method to a non-metaclass.
Inspecting objects and classes
Since classes are objects, we can also inspect them.
Inspect OrderedCollection withAll: #(4 5 6 1 2 3) and OrderedCollection.
Notice that in one case you are inspecting an instance of OrderedCollection and in the other case the OrderedCollection class itself. This can be a bit confusing, because the title bar of the inspector names the class of the object being inspected.
The inspector on OrderedCollection allows you to see the superclass, instance variables, method dictionary, and so on, of the OrderedCollection class, as shown in Figure \(\PageIndex{3}\).
