bug#58297: GOOPS slot accessor specialization and inheritance do not compose

[Mikael Djurfeldt <mikael@djurfeldt.com>]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

Unfortunately, I do not have time right now to look in the code, but this
might actually originally have been intended behavior.

The motivation for creating new accessor methods for child classes by
default could have been to ensure that it is possible to access slots using
a constant offset once the type dispatch is done. (There were originally
plans to actually also eliminate a lot of the type dispatch in GOOPS.)

It should be possible to get the CLOS behavior by defining a suitable meta
class. If *that* is not possible, it might be a bug, or at least a target
for a feature request.

Best regards,
Mikael

Den ons 5 okt. 2022 02:23Thompson, David <dthompson2@worcester.edu> skrev:

> In Guile, slot accessor specialization and inheritance do not compose.
> For example, you can't specialize an accessor's setter for a parent
> class and have it apply to a child class.  Every child class defines
> new slot accessor methods. which means that the specialized parent
> methods will not be called since the new methods take precedence.
>
> The code below demonstrates the issue:
>
>   (use-modules (oop goops))
>
>   (define-class <person> ()
>     (name #:init-keyword #:name #:accessor name))
>
>   (define-method ((setter name) (person <person>) new-name)
>     (display "renaming!\n")
>     (slot-set! person 'name new-name))
>
>   (define-class <child> (<person>))
>
>   (define p1 (make <person> #:name "Alice"))
>   (define p2 (make <child> #:name "Bob"))
>
>   ;; Only the first set! call uses the specialized setter method defined
>   ;; above.
>   (set! (name p1) "Ada")
>   (set! (name p2) "Ben")
>
> I would have expected the specialized setter method to apply to both
> <person> and <child> since <child> does not shadow the 'name' slot.
>
> I compared this behavior with that of Common Lisp and found that CLOS
> does not clobber the method from the parent class, as demonstrated by
> this example program that I tested with SBCL:
>
>   (defclass person ()
>     ((name :initarg :name :accessor name)))
>
>   (defmethod (setf name) (new-name (obj person))
>     (format t "renaming!~&")
>     (setf (slot-value obj 'name) new-name))
>
>   (defclass child (person) ())
>
>   (defvar p1 (make-instance 'person :name "Alice"))
>   (defvar p2 (make-instance 'child :name "Bob"))
>
>   ;; Both of these setf calls use the specialized setf method defined
>   ;; above.
>   (setf (name p1) "Ada")
>   (setf (name p2) "Ben")
>
> I find the Common Lisp behavior much more desirable.  Is this a bug or
> intended behavior?
>
> Thanks for reading,
>
> - Dave
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3423 bytes --]