[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Jacky Combs <combs@STC.LOCKHEED.COM>, Warren Harris <firstname.lastname@example.org>, @.lll-winken.UUCP@Xerox.COM, milich%whuts@att.ARPA, kanderso@BBN.COM, Joe Mohan <email@example.com>
- Subject: meta-object protocol
- From: Gregor.pa@Xerox.COM
- Date: Fri, 27 Jan 89 17:31 PST
- Cc: commonloops.pa@Xerox.COM
- Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
- In-reply-to: <8901170229.AA04700@topaz.STC.LOCKHEED.COM>, <4146.601069099@hplwhh>, <8901271524.AA17142@arisia.Xerox.COM>, The message of 27 Jan 89 09:20 PST from kanderso@BBN.COM, <8901272055.AA04723@hpljsm.HPL.HP.COM>
- Line-fold: no
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
I am trying to define my own metaclass using the (:metaclass
my-meta-class) option. I'm not having much success. Below is a
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
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 <firstname.lastname@example.org>
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.
- From: Joe Mohan <email@example.com>