[armedbear-devel] [closer-devel] Closer-mop support for ABCL

Pascal Costanza pc at p-cos.net
Sun Sep 9 16:46:20 UTC 2012

On 5 Sep 2012, at 12:33, Rudolf Schlatte <rudi at constantly.at> wrote:

> On Aug 26, 2012, at 22:37, Pascal Costanza <pc at p-cos.net> wrote:
>> OK, on to the next bug: It seems that anonymous classes are always considered subtypes of other classes. This is not correct. Here is transcript:
>> CL-USER(1): (defparameter *c1* (make-instance 'standard-class))
>> *C1*
>> CL-USER(2): (defparameter *c2* (make-instance 'standard-class))
>> *C2*
>> CL-USER(3): (subtypep *c1* *c2*)
>> T
>> T
> [etc]
> Nice.  For more fun and games, consider (setf (class-name *c1*) t) - instant universal superclass.  Anyway, both issues are hopefully fixed now.
> I wonder if this should be added to ansi-tests.

This would probably make sense.

On to the next bug:

CL-USER(1): (use-package :mop)

CL-USER(2): (defclass my-class (standard-class) ())

CL-USER(3): (defmethod slot-unbound ((class my-class) object slot) (print :foo) (call-next-method))

CL-USER(4): (defclass test () ((slot :accessor test-slot)) (:metaclass my-class))
#<MY-CLASS TEST {79BC8795}>

CL-USER(8): (make-instance 'test)
#<TEST {21BF4C80}>

CL-USER(9): (slot-boundp * 'slot)

CL-USER(10): (test-slot **)

#<THREAD "interpreter" {12EEA1E7}>: Debugger invoked on condition of type UNBOUND-SLOT
  The slot SLOT is unbound in the object #<TEST {21BF4C80}>.
  0: TOP-LEVEL Return to top level.

It seems that as soon as a method on slot-unbound is defined, slot-boundp returns t no matter whether the slot is bound or not. This should not be the case.

Another issue that I'm currently fighting with is initialization of class slots for classes for which I never create any instances:

(defclass test ()
  ((slot :initform 42 :allocation :class)))

(slot-value (class-prototype (find-class 'test)) 'slot) will report an unbound slot. This is probably defensible based on the HyperSpec and the CLOS MOP specification, but I doubt its useful. I believe that class slots should be initialized in finalize-inheritance the latest, and not only in shared-initialize on instances, to be useful for such scenarios. (But it's fine if you disagree, then I have to live with that and find a different solution…)


Pascal Costanza
The views expressed in this email are my own, and not those of my employer.

More information about the armedbear-devel mailing list