🚀 go-pugleaf

You have hit on a real problem in the CLOS MOP, at least as far as I am
concerned.  Unfortunately, given the current specification, it is pretty
hard to fix.  It depends a bit on how you look at it, but I guess I
would say the primary reason this can't be fixed is ``forward referenced
superclasses;'' or perhaps a combination of them and the rule that says
you can't change the class of a metaobject once it has been initialized.

If we got rid of forward referenced superclasses, your problem could be
fixed by providing a generic function called SUBCLASS-CLASS, which would
be called to determine the appropriate class of a subclass.  Some hair
would be needed to handle multiple inheritance, but that would be easy.

But, with forward referenced superclasses, we might not know that a
class needs to be an instance of something other than standard-class
until long after it is created, which causes problems with the change
class rule.  We might be able to get out of that by saying that one can
change the class of a class up until the time it is finalized; maybe
that is worth considering.

How serious a problem do people think this is?

One final note, in your message, you propose a fix that I don't
understand: 

   It seems that the only way of implementing this today is by
   defining an :around method on ENSURE-CLASS-USING-CLASS which
   is not exactly great to specialize, so maybe taking a look
   again at this part of the CLOS specification would be a good
   idea.

Can you elaborate on this?


Gregor