From unknown Sat Sep 06 14:24:21 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#58297 <58297@debbugs.gnu.org> To: bug#58297 <58297@debbugs.gnu.org> Subject: Status: GOOPS slot accessor specialization and inheritance do not compose Reply-To: bug#58297 <58297@debbugs.gnu.org> Date: Sat, 06 Sep 2025 21:24:21 +0000 retitle 58297 GOOPS slot accessor specialization and inheritance do not com= pose reassign 58297 guile submitter 58297 "Thompson, David" severity 58297 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 04 20:22:15 2022 Received: (at submit) by debbugs.gnu.org; 5 Oct 2022 00:22:15 +0000 Received: from localhost ([127.0.0.1]:55433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofsAw-0004XJ-Vm for submit@debbugs.gnu.org; Tue, 04 Oct 2022 20:22:15 -0400 Received: from lists.gnu.org ([209.51.188.17]:56122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ofsAs-0004X7-4C for submit@debbugs.gnu.org; Tue, 04 Oct 2022 20:22:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53940) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofsAr-0006p2-RE for bug-guile@gnu.org; Tue, 04 Oct 2022 20:22:10 -0400 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:47087) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ofsAp-0003VT-AE for bug-guile@gnu.org; Tue, 04 Oct 2022 20:22:09 -0400 Received: by mail-lj1-x229.google.com with SMTP id p5so17040703ljc.13 for ; Tue, 04 Oct 2022 17:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=worcester-edu.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=7rxrv6a6ElL9QhD5uplGlU+9B43834F/EX9b6IAZWrQ=; b=RQVtqKnfEOVIm4KfmXs+XSK0pA5u3Gd8vKh01mT23gg3etWm+zYSkbw5arJDCwDuGu K5QyEKHgEM5Hf/MwtqJmR/eXXsle4pwC+jarH9TgvuQ/aTVw5Ap94xNzdUud3GH6qpoF kLuY5LsRdQjWcHDIEcg9yAV8D11m8AaPv9pdiSio9Qj6ZPxJcXd+oNPRsRwmIscsKaB9 vq+0DHzpvuGxLeO7g6NxWWfbUlpkbdiudkmQTBVadsvNmeLILAgRQNkVZRfsypMGi0ZK jnJEgK4enChWLDGlCJceNsP2sImVQNvwbHTdP6SGhhRfFtz++gXGKV1zFpMPM9eoduNS uRhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=7rxrv6a6ElL9QhD5uplGlU+9B43834F/EX9b6IAZWrQ=; b=KCAIjZGgx78Nc0zaSuX7CV6Sba51G9uxwGDkx0zfgmdjtABYD0BnMTbpduTGVvPdCQ UngL79RQVKZQZa1fC6/t25kRgsCWEUJeP4Xt/wlww//fpycpOg80y4dAyXFVdih8EVso n0QqXCgcIs4S5hBcNaxYDsiT/vlzBRqRghBW2DQ8Wj1TtesQqecY32rEq0rjT71Mc2Je p6XAhkKf8O6SScGTsEZ3NIS0kQh1/wVI2lq5qBucwRb+dmsLIHmt8n/Q9AHIAoKREU/2 3vgtjjpXndSSlcJfxMijy57voqTD58WIlW0xxtRHp0yWa/Dit6jQzSWGF6VJZxzecO6P CtiQ== X-Gm-Message-State: ACrzQf2/Zf2qXQQAWw0jgaRKhETSQdMAc3xrB8JeOityPYc9uldfZb07 vgRwq2aYpbn7wCezJ/LdFIDrTbqFFMYtyRdnM7Z7PCirHtQylg== X-Google-Smtp-Source: AMsMyM7qCo5xTKJTVqezJsiuTypyPzlG9o1ed0xU2XG3JpExFocgi+nmNtrBS/czz9fsBt82KtrCLP6Hq4JZbKIqIc4= X-Received: by 2002:a2e:584:0:b0:26d:d9f6:3d91 with SMTP id 126-20020a2e0584000000b0026dd9f63d91mr4615938ljf.475.1664929322760; Tue, 04 Oct 2022 17:22:02 -0700 (PDT) MIME-Version: 1.0 From: "Thompson, David" Date: Tue, 4 Oct 2022 20:21:51 -0400 Message-ID: Subject: GOOPS slot accessor specialization and inheritance do not compose To: bug-guile@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::229; envelope-from=dthompson2@worcester.edu; helo=mail-lj1-x229.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) 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 () (name #:init-keyword #:name #:accessor name)) (define-method ((setter name) (person ) new-name) (display "renaming!\n") (slot-set! person 'name new-name)) (define-class ()) (define p1 (make #:name "Alice")) (define p2 (make #: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 and since 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 09:27:22 2022 Received: (at 58297) by debbugs.gnu.org; 5 Oct 2022 13:27:22 +0000 Received: from localhost ([127.0.0.1]:56257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4Qj-0006Hw-JQ for submit@debbugs.gnu.org; Wed, 05 Oct 2022 09:27:22 -0400 Received: from mail-ej1-f52.google.com ([209.85.218.52]:45826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1og4QT-0006HJ-5o for 58297@debbugs.gnu.org; Wed, 05 Oct 2022 09:27:20 -0400 Received: by mail-ej1-f52.google.com with SMTP id z23so18698680ejw.12 for <58297@debbugs.gnu.org>; Wed, 05 Oct 2022 06:27:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KLooRaiO1HwB5TMh7FzVsZkeSX+ruItZzwYyjHsaEo0=; b=nybaAfAa2r3kcWd71iK3Yg7wt7CTEEEXZt6w1U5fALnDmxXYl4T78AQzL34ZXtrpEU nPobRonMH5D7EsNOR2WlQvRnN0xGdeZIYsmfGJTB+lfu3E/BRlymFM1FJzTX2Gsyp1rZ cPjLhkcNQ/ALOt3OP5apa8Oc6afXWuZzdc3kKtoJxu5ab2MvyPUSgCwhaUByTJsNAEvH Pktk3uWA7ra3hZFU9rqIVH0Em1reItHKLobhm9RZ7dh398MQ1StPZ4Ty5QWWuqhdmaT5 QWvwqB8sj5D0rvyczv6tZjuUh/qa6HvF3l6p2MtRTfsOBZWOqiHWtkIR1bbxxdwoFfR8 AO3g== X-Gm-Message-State: ACrzQf06bJHycQj6J5w+0JM3++eduOoRszyERZ006Otwx/3Vnj+MrieN vbMw4T0gOtyGkyv8daIq80WHmR9txJMdue8x7jQ= X-Google-Smtp-Source: AMsMyM4Yk3THbZTn9r0DixEcIUMOYIPGaHV1YUldKJuG1nhoe+dAG63Y1W/Bg40kQV23m8X1lxu8j+7VfaDqGAM3Vuo= X-Received: by 2002:a17:907:d02:b0:78a:6374:f444 with SMTP id gn2-20020a1709070d0200b0078a6374f444mr14188618ejc.86.1664976419357; Wed, 05 Oct 2022 06:26:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mikael Djurfeldt Date: Wed, 5 Oct 2022 15:26:48 +0200 Message-ID: Subject: Re: bug#58297: GOOPS slot accessor specialization and inheritance do not compose To: "Thompson, David" Content-Type: multipart/alternative; boundary="0000000000000907ef05ea49889b" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 58297 Cc: Mikael Djurfeldt , 58297@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: mikael@djurfeldt.com Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --0000000000000907ef05ea49889b Content-Type: text/plain; charset="UTF-8" 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 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 () > (name #:init-keyword #:name #:accessor name)) > > (define-method ((setter name) (person ) new-name) > (display "renaming!\n") > (slot-set! person 'name new-name)) > > (define-class ()) > > (define p1 (make #:name "Alice")) > (define p2 (make #: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 > and since 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 > > > > --0000000000000907ef05ea49889b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unfortunately, I do not have time right now to look in th= e code, but this might actually originally have been intended behavior.
The motivation for creating new a= ccessor 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 dispa= tch 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 suit= able 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. 2= 022 02:23Thompson, David <dt= hompson2@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.=C2=A0 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:

=C2=A0 (use-modules (oop goops))

=C2=A0 (define-class <person> ()
=C2=A0 =C2=A0 (name #:init-keyword #:name #:accessor name))

=C2=A0 (define-method ((setter name) (person <person>) new-name)
=C2=A0 =C2=A0 (display "renaming!\n")
=C2=A0 =C2=A0 (slot-set! person 'name new-name))

=C2=A0 (define-class <child> (<person>))

=C2=A0 (define p1 (make <person> #:name "Alice"))
=C2=A0 (define p2 (make <child> #:name "Bob"))

=C2=A0 ;; Only the first set! call uses the specialized setter method defin= ed
=C2=A0 ;; above.
=C2=A0 (set! (name p1) "Ada")
=C2=A0 (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 &#= 39;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:

=C2=A0 (defclass person ()
=C2=A0 =C2=A0 ((name :initarg :name :accessor name)))

=C2=A0 (defmethod (setf name) (new-name (obj person))
=C2=A0 =C2=A0 (format t "renaming!~&")
=C2=A0 =C2=A0 (setf (slot-value obj 'name) new-name))

=C2=A0 (defclass child (person) ())

=C2=A0 (defvar p1 (make-instance 'person :name "Alice"))
=C2=A0 (defvar p2 (make-instance 'child :name "Bob"))

=C2=A0 ;; Both of these setf calls use the specialized setf method defined<= br> =C2=A0 ;; above.
=C2=A0 (setf (name p1) "Ada")
=C2=A0 (setf (name p2) "Ben")

I find the Common Lisp behavior much more desirable.=C2=A0 Is this a bug or=
intended behavior?

Thanks for reading,

- Dave



--0000000000000907ef05ea49889b--