MetaClass Inheritance - NOT
I think I answered my own question...
Metaclasses are used to coax the compiler of classes into interpreting various subclasses of slot-definitions. Hence only one metaclass needs to be defined, along with multiple slot-definition classes, where the slot-defs define the nature of persistent or computed slots. The metaclass itself merely enables recognition of these user defined slot-defs, e.g., through compute-effective-slot-definition.
And then at runtime, the metaclass allows the slot-value-using-class, etc., to vector to routines that handle each kind of user defined slot access.
So in the end, metaclasses have nothing to do with what kind of behavior your new class should exhibit, in the sense of describe classes of behavior. Those behaviors come from the underlying slot definitions, and the slot recognizers you build into the metaclass directed slot-value-using-class.
Sheesh, this stuff can become confusing. The metaclass hierarchy is not the same kind of thing as the usual CLOS heirarchy, even though the both live in the same universe.
FWIW: the admonition to use the class option :optimize-slot-access nil, is really not necessary, unless you need to have normal slots (allocation instance or class) go through the slot-value-using-class protocol. It isn't required for specialized slots.
Dr. David McClain
Chief Technical Officer
Refined Audiometrics Laboratory
4391 N. Camino Ferreo
Tucson, AZ 85750
phone: 1.520.390.3995
Re: MetaClass Inheritance - NOT
David McClain wrote:
> Metaclasses are used to coax the compiler of classes into
> interpreting various subclasses of slot-definitions. Hence only one
> metaclass needs to be defined, along with multiple slot-definition
> classes, where the slot-defs define the nature of persistent or
> computed slots. The metaclass itself merely enables recognition of
> these user defined slot-defs, e.g., through compute-effective-slot-
> definition.
Yes, I think this is roughly correct.
> So in the end, metaclasses have nothing to do with what kind of
> behavior your new class should exhibit
But here you're going too far.
Metaclasses can have properties themselves (e.g. you can define slots
for the /metaclass/, the values of these 'metaclass slots' can be
changed and these values can also be used to modify the behaviour of
classes that are instances of that metaclass).
For example, in Rucksack, I added a class option :INDEX, which
corresponds to a slot called INDEX for Rucksack's metaclass
PERSISTENT-CLASS:
(defclass persistent-class (standard-class)
((index :initarg :index :initform nil
:documentation "Can be either NIL (for no class index) or T
(for the normal class index). Default value is NIL.")))
So you can say
(defclass person ()
(... some slots here ...)
(:metaclass persistent-class)
(:index t))
This :INDEX T is passed on to INITIALIZE-INSTANCE of the PERSON class
object (which has metaclass PERSISTENT-CLASS). So the PERSON class
object (i.e. the result of (FIND-CLASS 'PERSON)) will have a slot
called INDEX with the value T. Because of this T value, Rucksack
will index all instances of the class PERSON, which makes it possible
to find them whenever you need them.
So this definitely has something to do with 'the kind of behaviour that
the new class should exhibit', regardless of any special slot-definition
subclasses that PERSON may or may not use.
> Sheesh, this stuff can become confusing. The metaclass hierarchy is
> not the same kind of thing as the usual CLOS heirarchy, even though
> the both live in the same universe.
Yes. You could say that the metaclasses live in a different plane of
the same universe ;-)
Arthur