[Openmcl-devel] Custom Meta Classes

Sven Van Caekenberghe sven at beta9.be
Thu Jan 15 06:13:28 PST 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
>> get-info)))
>> ? (defclass foo () ((bar :accessor get-bar)) (:metaclass
>> foo-meta-class))
>>> Error in process listener(1): The class #<STANDARD-CLASS
>> STANDARD-OBJECT> was specified as a
>>>                               super-class of the class
>>>                               but the meta-classes #<STANDARD-CLASS
>>>                               #<STANDARD-CLASS FOO-META-CLASS> are
>> incompatible.
> 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 
> bothered
> 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!
? *features*
? (defclass foo-meta-class (standard-class) ((extra-info :accessor 
? (defmethod validate-superclass ((class foo-meta-class) (super 
standard-class)) t)
? (defclass foo () ((bar :accessor get-bar)) (:metaclass 
? (make-instance 'foo)
#<FOO #x53759BE>
? (describe *)
#<FOO #x53759BE>
Wrapper: #<CCL::CLASS-WRAPPER FOO #x53768A6>
Instance slots
BAR: #<Unbound>



More information about the Openmcl-devel mailing list