+ Jim Newton <[EMAIL PROTECTED]>:
| In the following code i see very different behavior from CMUCL
| and CLISP. Can someone tell me which is the correct behavior?
I am no expert, but I'll wager that CMUCL is right. Let the experts
pick my reasoning apart if they disagree.
| In CMUCL, I see both the primary method being called and also
| the after method. However, from CLISP only the primary method
| seems to be called.
First, off, I think all the package stuff in the example is totally
incidental. Nowhere do I see a potential naming conflict between
symbols here. So, stripped to essentials, the example is
| (defclass mixin-foo nil nil)
| (defclass class-foo (mixin-foo) nil)
| (defgeneric fun (x))
| (defmethod fun ((x class-foo)) ...)
|
| (defclass class-bar nil nil)
| (defmethod fun :after ((x class-bar)) ...)
|
| ;; redefine class class-foo
| (defclass mixin-foo (class-bar) nil)
|
| (fun (make-instance 'class-foo))
So before the redifinition, the class hiearchy is
mixin-foo
class-foo <-- primary fun method applicable
class-bar <-- :after fun method applicable
while afterwards, it is
class-bar <-- :after fun method applicable
mixin-foo
class-foo <-- primary fun method applicable
I think the following extract from CLHS, about defclass, is pertinent:
If a class with the same proper name already exists and that class
is an instance of standard-class, and if the defclass form for the
definition of the new class specifies a class of class
standard-class, the existing class is redefined, and instances of it
(and its subclasses) are updated to the new definition at the time
that they are next accessed. For details, see Section 4.3.6
(Redefining Classes).
Section 4.3.6 only specifies what happens to :reader, :writer or
:accessor methods, not what happens to user supplied methods. But
surely, in that case removing such methods seems unwarranted. Also,
Redefining a class modifies the existing class object to reflect the
new class definition; it does not create a new class object for the
class.
This indicates to me very strongly that any methods defined before the
change will not only still be there, but they will be applicable to
the redefined class, since the class object really is the same. And
so, presumably, the associated type is still the same.
- Harald
