[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mikael Djurfeldt
Subject: bug#58297: GOOPS slot accessor specialization and inheritance do not compose
Date: Wed, 5 Oct 2022 15:26:48 +0200

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,

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]