[Openmcl-devel] Custom Meta Classes

[Gary Byers]

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.


>
> Sven
>
> --
> Sven Van Caekenberghe - mailto:sven at beta9.be
> Beta Nine - software engineering - http://www.beta9.be
> .Mac - svc at mac.com - http://homepage.mac.com/svc
>
> "Lisp isn't a language, it's a building material." - Alan Kay
>