MOP protocol/constructors for conditions
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
The following works (as in, does not error) on SBCL at the moment:
(define-condition my-condition () ())
(defmethod initialize-instance :after ((warning my-condition) &key)
(print "boo"))
This constructor method is only called if I call:
(make-instance 'my-condition)
and not
(make-condition 'my-condition)
This behaviour is already present in CCL, ECL, CLISP, ABCL.
Please adapt MAKE-CONDITION to call MAKE-INSTANCE, so the constructors for INITIALIZE-INSTANCE are called.
It seems that these two ways of creating condition instances are independent:
CL-USER> (trace make-condition)
(MAKE-CONDITION)
CL-USER> (make-instance 'style-warning)
#<STYLE-WARNING {1002F8D193}>
CL-USER> (make-condition 'style-warning)
0: (MAKE-CONDITION STYLE-WARNING)
0: MAKE-CONDITION returned #<STYLE-WARNING {100305A933}>
#<STYLE-WARNING {100305A933}>
summary: |
- Change MAKE-CONDITION to call MAKE-INSTANCE + MOP protocol/constructors for conditions |
MAKE-CONDITION is not called in MAKE-INSTANCE as ALLOCATE-INSTANCE calls ALLOCATE-CONDITION directly.
https:/ /github. com/sbcl/ sbcl/blob/ master/ src/pcl/ slots.lisp# L486
In a fully bootstrapped CL, it seems that the following redefinition does not break anything:
(defun make-condition (condition-type &rest args)
(apply #'make-instance condition-type args))
The question is - what if MAKE-CONDITION is called before MAKE-INSTANCE is functional - or rather, should this old MAKE-CONDITION stay around until, late in the bootstrapping process, it is replaceable by the new version. It would also require the old MAKE-CONDITION be declared notinline so the redefinition is possible.