[armedbear-devel] Other findings (was Re: Questions about r14452 (Fix cl-cont))

[Rudolf Schlatte]

On Apr 2, 2013, at 21:40, Erik Huelsmann <ehuels at gmail.com> wrote:

> 
> 
> 
> Well, to some extent I can see your problem. Indeed there seem to be no slots in the 'MOP:FUNCALLABLE-STANDARD-OBJECT class. The layoutFuncallableStandardClass is what confused me, but that's indeed the layout of the metaclass.
> 
> So, you're correct that the fix works by accident. The solution should be to add a slot by the name 'MOP::NAME to the FUNCALLABLE-STANDARD-OBJECT. That slot can contain the name of the object (ie function) for which the item is defined. In that case, we should probably remove the direct slot MOP::NAME on the standard generic function, since it's already defined on the superclass if we decide to do that.
> 
> 
> 
> While studying this problem using DESCRIBE, it seems our current implementation dispatches (DESCRIBE (MAKE-INSTANCE 'CL-CONT::FUNCALLABLE/CC)) the wrong way: to the T way instead of the STANDARD-OBJECT way...
> 
> Yet more to investigate...

For this general kind of problem, I'm currently partial to using Lisp-side operators + calling Lisp functions instead of using instanceof / Java-side cast + method call.  E.g., FuncallableStandardObject.java:202:

        if (Symbol.SUBTYPEP.execute(arg, StandardClass.STANDARD_GENERIC_FUNCTION) != NIL) {
          return new StandardGenericFunction((Layout)l);
        } else {
          return new FuncallableStandardObject((Layout)l);
        }

(The condition was "instanceof StandardGenericFunction" until recently).
This seems more robust, and hopefully prepares us for transferring stuff Lisp-side eventually.

Rudi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20130402/c7333b4e/attachment.html>