GNU bug report logs - #58297
GOOPS slot accessor specialization and inheritance do not compose

Previous Next

To reply to this bug, email your comments to 58297 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Thompson, David" <dthompson2 <at> worcester.edu>
To: bug-guile <at> gnu.org
Subject: GOOPS slot accessor specialization and inheritance do not compose
Date: Tue, 4 Oct 2022 20:21:51 -0400

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

Message #8 received at 58297 <at> debbugs.gnu.org (full text, mbox):

From: Mikael Djurfeldt <mikael <at> djurfeldt.com>
To: "Thompson, David" <dthompson2 <at> worcester.edu>
Cc: Mikael Djurfeldt <mikael <at> djurfeldt.com>, 58297 <at> debbugs.gnu.org
Subject: Re: bug#58297: GOOPS slot accessor specialization and inheritance do
 not compose
Date: Wed, 5 Oct 2022 15:26:48 +0200

[Message part 1 (text/plain, inline)]

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 <at> 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
>
>
>
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.