[Openmcl-devel] Custom Meta Classes

[Sven Van Caekenberghe]

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)))
>> #<STANDARD-CLASS FOO-META-CLASS>
>> ? (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
>> #<FOO-META-CLASS FOO>;
>>>                               but the meta-classes #<STANDARD-CLASS
>> STANDARD-CLASS> and
>>>                               #<STANDARD-CLASS FOO-META-CLASS> are
>> incompatible.
>>> 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 
> 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*
(: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 
get-info)))
#<STANDARD-CLASS FOO-META-CLASS>
? (defmethod validate-superclass ((class foo-meta-class) (super 
standard-class)) t)
#<STANDARD-METHOD VALIDATE-SUPERCLASS (FOO-META-CLASS STANDARD-CLASS)>
? (defclass foo () ((bar :accessor get-bar)) (:metaclass 
foo-meta-class))
#<FOO-META-CLASS FOO>
? (make-instance 'foo)
#<FOO #x53759BE>
? (describe *)
#<FOO #x53759BE>
Class: #<FOO-META-CLASS FOO>
Wrapper: #<CCL::CLASS-WRAPPER FOO #x53768A6>
Instance slots
BAR: #<Unbound>

Thx,

Sven