=pod =head1 Meta-Meta-Classes ... or How to twist your brain up in knots without even trying. Note that the "Meta Meta Class" used in this document does I exist in the implemented language at all; more concretely, it is the I of the class model in the host language. =head1 Introduction This document is an ongoing attempt to clarify (and hopefully simplify) the all too hairy topic of MetaClasses and as a result provide a working basis for the Perl-6 Meta-Model. This may not be the I nor is it the I to view the concept of MetaClasses; many books have been written on the subject which all use subtly different concepts and terminology. =head1 The Object Environment Let us assume for a moment that all our object's live in an I environment (B), which is a finite set of objects, each of which is identified with a unique object reference. Here is a diagram of the entire object environment: +-{Instance}-+ +--{Class}--+ +{MetaClass}+ +{MetaMetaClass}+ | | | | | | | | | ------ | | ----- | | ------- | | ----------- | | ( $foo )------>( Foo )----->( Class )---->( MetaClass ) | | ------ | | ----- | | ------- | | ----------- | | | | | | | | | +------------+ +-----------+ +-----------+ +---------------+ Our object environment has a set of rules which help to define the elements that exist within it. However, before we do that, we must first make a point about the nomenclature found in the document. =head3 Meta-Nomenclature MetaClass systems are highly reflective by nature. This results in a very cyclical nomenclature, which at times can seem as if it is using itself to describe itself. Because of this we will try to be as consistent as possible in our nomenclature, and describe the "rules" of it here. First, it needs to be noted that objects themselves are primative creatures in this environment. When we use the term object, we are refering to this primative element, and not the instance of a class. When we write "type of XXX", we are moving upwards in the object environment (to the right on the above diagram); the type of an Instance is a Class, the type of a Class is a MetaClass, and the type of a MetaClass is a MetaMetaClass. When we write "instance of XXX", we are moving downwards (or to the left in the diagram). An instance of a MetaMetaClass is a MetaClass, an instance of a MetaClass is a Class, and an instance of a Class is an Instance. To stay on the same level, we use the term "XXX object". There is also an important distinction between a noun "class", and a proper noun "Class". The proper noun "Class" refers specifically to the Class MetaClass, while "class" will refer to the class of which an object is an instance of (however in most cases we will use "type" here instead of class). =head2 Rules of the object environment =over 4 =item B is an instance of some C> These are the occupants of our environment B. Every noted C has a uniquely associated entity called a C. =item B is an instance of a C> These objects are what would normally be described as your program's I; ie, objects that are I will be called "Dog", "Tree", etc. =item B is an instance of some C> These objects are what would normally be described as your B I, or program I. These will be called "Class", "Role", etc. =item B is an instance of the underlying system> In theory, we could extend this relationship to any level. However, it simply does not make much sense to deal with these objects directly, they are the building block on which the above are created. =back =head1 So what is a Meta-Meta-Class anyway? Lets first define the other objects in our environment. =head2 What is an object? An object is a primative element in our environment. For the purposes of illustration we will use simple data-dictionaries/perl-ish hashes. Here is an example of how an object describing a book might look like: { Book => { 'title' => "VALIS", 'author' => "Phillip K. Dick", } } =head2 So what is an Instance? An I is simply an object with a c slot whose value is a reference to the class from which the instance is derived, and a set of instance variables (which are defined by the class (and which we will see later)). So a C instance of the class I would look like this: { 'class' => Book Book => { 'title' => "VALIS", 'author' => "Phillip K. Dick", } } =head2 So what is a Class? A I is itself just another data dictionary, however its structure is a bit more complex. First, our class must have a name. A class also needs to have a set of default instance variables from which new instances can be created. Next, our class needs to have a method table, which is just another data dictionary whose keys are labels and whose values are code references. This table is seperate from the instance variables becuase methods remain in the class, and are not copied into the instance. And lastly, we have inheritance. Our class needs to have parents, which we represent as an ordered list of other I objects. So given that, our I class might be structured something like this: { 'class' => Class, Class => { 'name' => 'Book', 'parents' => [ ... ], 'instance_vars' => { Book => { title => '', author => '' } }, 'method_table' => { 'get_author' => sub { ... }, 'set_author' => sub { ... }, 'get_title' => sub { ... }, 'set_title' => sub { ... }, } } } As you can see, our I class is itself an instance of the meta-class I. A list of supported instance variables and methods can be found by accumulating a properly sorted unique list of all a class's instance_vars and method_tables merged with those of its ancestors. These lists make it is possible to determine the instance variable and method resolution order. =head2 So what is a MetaClass? Once again, we can represent our meta-class as a data dictionary. Here is an example of how the meta-class I would look: { 'class' => MetaClass, MetaClass => { 'name' => 'Class', 'parents' => [ ... ], 'instance_vars' => { Class => { 'name' => "", 'parents' => [], 'instance_vars' => {}, 'method_table' => {} } }, 'method_table' => { 'create_instance' => sub { return { 'class' => Class, Class. } } } } } The C for a I are basically those of an empty parent-less class, nothing more, nothing less. The simplicity of this notion can be somewhat difficult to swallow. The tempation is to make it seem much more complex, but in reality it is not. We also take this opportunity to define a C method for our I which basically just creates a new data dictionary, adding the required 'class' key and value pair, along with a copy of the C. Again, it need not be any more complex than that. =head2 So what is a MetaMetaClass? Now we are back to our original question, and hopefully by now the answer is quite obvious. A MetaMetaClass is simply a concrete implementation of the data structures we have been constructing above. Our MetaMetaClass is the root of our object hierarchy, and the object from which all others can be defined. "That's all?" you say. "But it can't possibly be all!". It is of course important to keep a few things in mind, the first of which is that this MetaMetaClass is actually independent of a given programming language. That it is not something which the "user" should ever really have access too. It is a part of the compiler and/or runtime environment upon which a programming language resides. The second thing is ... hmmm, what was it? =head1 Why do we need all this abstraction? What follows is a (slightly edited) snippet of a converstation which took place on IRC. why do we need one more level after classes? and how come just one more level is enough? what do you do with that? that kind of stuff well, there is not a really a quick answer but I will try :) basically it is this a class needs to be something an instance of something that is because there are more than one class in any system why not an object, like in java? well the Object type in Java is sort of like a metaclass okay it is the base from which all things are derived just automagically yes, i see that. the heirarchy must come to a point/root in Java it is the Object in Smalltalk it is MetaClass (i think) take a theoretical object model uh huh where we have basic Classes which have methods and properties say you want to add Final classes like Java how would you do that? subclass Class of course but this means that Class itself must be an instance of something okay, yes remember too that this is not something the "user" of the language ever sees yup that was clear enough from your explanation so you can subclass Class and get FinalClass so this brings up the question, what is Class an instance of MetaClass so you can stop your model at MetaClass and say that is the root OR you can go one level higher which then makes it easier to have Roles, Classes, Traits, etc. the MetaMetaClass is the root now, and each MetaClass is an instance of it some of the MetaClasses in Perl6 will be Role, Class mugwump also included Module and Package too the perl code in ext/, is it part of the actual implementation of oop in pugs? no has autrijus assimilated that into the haskell code? right now it is just a prototype to play around with an object model ah, okay he might eventually do that if it works out i see. this is cool stuff. but it is easier to prototype in perl (5|6) then it is in Haskell (at least for me) yeah, me too. meta-meta-hacking :) basically you are modeling the class/object system yes, i get that. i think java is a big help here because it's so consistent I will try to update the meta-meta doc later today okay thanks for the brief. np I always find that the best way to explain things is to use examples. So for an example of how one might use meta-classes (not meta-meta-classes), please see the F document in the folder as this document. =head1 ACKNOWLEDGEMENTS Much of what is found in this document is a direct rip-off of the contents of the first few chapter of this book (defined here as an instance of a Book class): { 'class' => Book, Book => { 'title' => "Putting Metaclasses to Work", 'authors' => [ 'Ira R. Forman', 'Scott H. Danforth' ], 'publisher' => 'Addison-Wesley' 'isbn' => 0-201-43305-2, } } However, despite my plagarism/summariazation, I still take responsibility for all errors, inconsistencies or outright lies this document might contain. =head1 AUTHORS Stevan Little Estevan@iinteractive.comE Sam Vilain Esamv@cpan.orgE =cut