[Openmcl-devel] Custom Meta Classes
Sven Van Caekenberghe
sven at beta9.be
Thu Jan 15 09:13:28 EST 2004
On 15 Jan 2004, at 12:11, Gary Byers wrote:
> On Thu, 15 Jan 2004, Sven Van Caekenberghe wrote:
>> In OpenMCL 0.13.x I could define my own meta classes like this:
> i.e., without having to define one or more VALIDATE-SUPERCLASS
> methods which describe which subclass relationships between instances
> of your new metaclass and those of other metaclasses make sense.
>> This works in LispWorks 4.3 as well.
>> In OpenMCL 0.14.x I get the following error:
>> Welcome to OpenMCL Version (Alpha: Darwin) 0.14-031220!
>> ? (defclass foo-meta-class (standard-class) ((extra-info :accessor
>> #<STANDARD-CLASS FOO-META-CLASS>
>> ? (defclass foo () ((bar :accessor get-bar)) (:metaclass
>>> Error in process listener(1): The class #<STANDARD-CLASS
>> STANDARD-OBJECT> was specified as a
>>> super-class of the class
>> #<FOO-META-CLASS FOO>;
>>> but the meta-classes #<STANDARD-CLASS
>> STANDARD-CLASS> and
>>> #<STANDARD-CLASS FOO-META-CLASS> are
>>> While executing: #<CCL::STANDARD-KERNEL-METHOD SHARED-INITIALIZE
>> :AFTER (CCL::SLOTS-CLASS T)>
> If the error message
> (a) indented a little better
> (b) reminded you that the MOP requires that an applicable method on
> VALIDATE-SUPERCLASS return true to avoid this error.
> this may have been less surprising.
>> This vaguely reminds me of an error I saw in CMUCL with the same code
>> where you had to validate the new meta class...
> It should. There seem to be three course of action that an
> implementation could take when the user tries to define a subclass
> of an existing class (implicitly STANDARD-OBJECT) and the metaclasses
> of the class and subclass are different:
> 1) quietly assume that the programmer knows what (s)he is doing
> 2) require that a protocol be followed to determine whether this
> is intentional
> 3) completely ignore the issue.
> The MOP requires that implementations follow (2), and uses the generic
> function VALIDATE-SUPERCLASS to implement the protocol. This is a
> conservative approach, but it doesn't strike me as being a bad idea
> to require that the programmer think about the issue long enough to
> write a VALIDATE-SUPERCLASS method.
> Strategy (1) is a little more in keeping with Lisp's "give 'em enough
> rope" philosophy. I could imagine wanting to set a variable somewhere
> whose effect was to assert that all possible superclass relationships
> that I tried to introduce were valid, and that I'd rather not be
> with this fairly obscure issue and will take responsibility for doing
> something catastrophic.
> Previous versions of OpenMCL followed strategy (3). This is one of
> several differences that the MOP introduces, and I suspect that many
> people would find a summary of those differences helpful.
OK, it now works:
Welcome to OpenMCL Version (Alpha: Darwin) 0.14-031220!
(:PRIMARY-CLASSES :CCL :CCL-2 :CCL-3 :CCL-4 :CORAL :COMMON-LISP :MCL
:OPENMCL :ANSI-CL :PROCESSES :UNIX :OPENMCL-NATIVE-THREADS
:OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL-MOP-2
:INTERFACES-2 :POWERPC :PPC-TARGET :PPC-CLOS :PPC32-TARGET :PPC32-HOST
:DARWINPPC-TARGET :DARWINPPC-HOST :DARWIN :POWEROPEN-TARGET)
? (defclass foo-meta-class (standard-class) ((extra-info :accessor
? (defmethod validate-superclass ((class foo-meta-class) (super
#<STANDARD-METHOD VALIDATE-SUPERCLASS (FOO-META-CLASS STANDARD-CLASS)>
? (defclass foo () ((bar :accessor get-bar)) (:metaclass
? (make-instance 'foo)
? (describe *)
Class: #<FOO-META-CLASS FOO>
Wrapper: #<CCL::CLASS-WRAPPER FOO #x53768A6>
More information about the Openmcl-devel