[Openmcl-devel] I want to make this change but I want to run it by everyone first

Gary Byers gb at clozure.com
Sun Apr 17 15:52:30 PDT 2005

On Sun, 17 Apr 2005, alex crain wrote:

> (Particularly Gary and Randal
> This goes back to a discussion that Dan Knapp and I had on the board in
> january.
> The problem:
> Given that there is a class that has both lisp and foreign slots,
> if that class is instantiated on the AppKit side of things,
> AppKit will allocate the class but won't invoke MAKE-INSTANCE because
> AppKit knows nothing about the lisp class system.
> This problem manifests itself whenever a class is instantiated on the
> AppKit side - nib files, documents, etc.
> I made the following change and it works, but I'm not convinced it's
> the best way.

I don't think that we can guarantee that the lisp slots-vector exists
if lisp code wasn't involved in the creation of the instance, so it
seems that we have to create and initialize the slots-vector lazily.
This -does- mean that INITIALIZE-INSTANCE might get run quite a while
after the foreign side of the instance has been initialized, and you
may have to be aware of that.  (I can't think of a concrete example
of a case where this would matter, but there may be such a case.)

> I added a check so that if we can't find a slot vector then we try to
> explicitly create it
> and if that works then we go ahead and call INITIALIZE-INSTANCE to
> finish the job.
> If we can't explicitly create the slot, then we're confused and we die
> appropriately.

The error case (seemingly) can only happen on attempts to reference
a lisp slot in an object that doesn't have any lisp slots.  In the
short term, it's probably OK to just signal a generic error in this
case (as has been happening all along ...); it'd probably be slightly
better to try to fit this in with the SLOT-MISSING protocol in the
longer term (that'd need to happen in higher-level code.)

More information about the Openmcl-devel mailing list