Opened 14 years ago
Closed 14 years ago
#119 closed defect (fixed)
Unexpected CLOS shared slot initialization order
Reported by: | Mark Evenson | Owned by: | analysis |
---|---|---|---|
Priority: | major | Milestone: | unscheduled |
Component: | CLOS | Version: | 1.0 |
Keywords: | clos unexpected-behavior | Cc: | |
Parent Tickets: |
Description
Didier Verner writes:
it seems that until now, I've been relying on a non-standard behavior, namely the fact that shared slots with an :initform are initialized before the first actual class instance is created: (defclass test () ((slot :allocation :class :initform t))) (defmethod initialize-instance :before ((test test) &key) (format t "Slot boundp: ~A~%" (slot-boundp test 'slot))) CL-USER> (make-instance 'test) Slot boundp: NIL #<TEST {C5D3B8}> CL-USER> (make-instance 'test) Slot boundp: T #<TEST {14563D4}> CL-USER> I just fell on this because every other Common Lisp implementation I've tried gives T and T here. Is it due to the way CLOS is implemented in ABCL, and is there a chance that this can be improved?
Change History (3)
comment:1 Changed 14 years ago by
comment:2 Changed 14 years ago by
Didier Verna follows up with:
So, after some discussion on cll and pro@, I have some precisions about
this. From what I understand of CLHS now, an implementation is not
required to initialize a shared slot at class creation time from the
initform (so far so good for ABCL).
However, the iniform of a shared slot must be evaluated in the dynamic
environment of the defclass call, even if it's not used to initialize
the slot right now (see the defclass page). The following test shows
that ABCL's behavior is currently incorrect in that regard:
(defclass fungy ()
((x :allocation :class
:initform (progn
(format *debug-io* "~&x initform~%")
6)
:initarg :x)
(y :initform (progn
(format *debug-io* "~&y initform~%")
7)
:initarg :y)))
CL-USER(1): (defclass fungy () ...)
#<STANDARD-CLASS FUNGY {1AEE513}>
CL-USER(2): (make-instance 'fungy)
x initform <========= this is too late
y initform
#<FUNGY {18C2354}>
comment:3 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Subject broached in comp.lang.lisp:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/59817da18664df33#
Side question: Is there a URI for comp.lang.lisp threads that doesn't go through the GOOG?