meta-object protocol

[Gregor.pa@Xerox.COM]

    Date: Mon, 16 Jan 89 20:29:06 CST
    From: Jacky Combs <combs@STC.LOCKHEED.COM>

    For example, I have defined "my-meta-class" as a subclass of
    "standard-class" so that I can define additional slots and
    methods for "my-meta-class".  This definition works fine, but
    when I try to define a class as an instance of "my-meta-class"
    I get an error message from the method 
    "check-super-metaclass-compatibility" telling me that a class
    and it's super have to be instances of the same class.  Does
    this mean that PCL only supports a single metaclass and that
    ALL classes (including system classes have to be instances of
    the same class)?

    Date: Fri, 27 Jan 89 07:24:10 PST
    From:"@lll-winken.UUCP", milich%whuts@att.ARPA

    I am trying to define my own metaclass using the (:metaclass 
    my-meta-class) option. I'm not having much success. Below is a
    simple example:

Jacky Combs and Greg Milich both report the same problem.  As Ken
Anderson has pointed out to both of them, all that is happening is
that the default behavior of check-super-metaclass-compatibility is
to signal an error.  All that needs to be done to solve this problem
is to define a method on check-super-metaclass-compatibility that
returns true rather than signalling an error.

Some comments on why this is:

The key point, is that when two incompatible metaclasses are mixed
improperly, the results are undefined.  (Note that I am using "results
are undefined" as a technical term with the meaning defined in the CLOS
specification).

This is an important part of the design of the metaobject protocol.
This allows the implementor of a metaclass to simply assume that all
"super-metaclasses" of that metaclass will obey whatever special
contract is required.  Once two metaclasses enter into the super
metaclasses contract, neither has to check to see if the other is
violating the contract, they assume validity on the other's part.  This
is why the willingess of the two metaclasses to enter into the contract
must be checked up front, before the classes are linked.  So, the
check-super-metaclass-compatibility generic function is called before
the classes are linked.

    Date: Tue, 17 Jan 89 11:38:19 PST
    From: Warren Harris <harris%hplwhh@hplabs.hp.com>

    In this example I saw no reason why the super of OBJECT
    should be incompatible with MY-OBJECT.  *All* functionality
    of STANDARD-CLASS has been inherited into MY-CLASS.

It is true that in many common cases, the newly defined metaclass is
compatible.   But, CLOS has no way of knowing that.  After all, it can't
analyze your code to determine it!

So, the decision we made was to have the standard method on
check-super-metaclass-compatibility signal an error.  The rationale is
that since defining a new metaclass requires thinking so much about
whether you are going to break the contract with standard-class anyways,
the programmer should be forced to explicitly claim compatibility in
this way.  In some cases, the super-metaclass can be frobbed in some way
and only then can the classes be compatible.
-------