From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.bugs Subject: bug#58297: GOOPS slot accessor specialization and inheritance do not compose Date: Wed, 5 Oct 2022 15:26:48 +0200 Message-ID: References: Reply-To: mikael@djurfeldt.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000907ef05ea49889b" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11593"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Mikael Djurfeldt , 58297@debbugs.gnu.org To: "Thompson, David" Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Wed Oct 05 15:28:29 2022 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1og4Ro-0002pc-Gw for guile-bugs@m.gmane-mx.org; Wed, 05 Oct 2022 15:28:28 +0200 Original-Received: from localhost ([::1]:41158 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1og4Rn-0001fB-8s for guile-bugs@m.gmane-mx.org; Wed, 05 Oct 2022 09:28:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55918) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1og4RP-0001bt-8b for bug-guile@gnu.org; Wed, 05 Oct 2022 09:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57184) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1og4RO-0004d1-M7 for bug-guile@gnu.org; Wed, 05 Oct 2022 09:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1og4RO-0006J9-Hf for bug-guile@gnu.org; Wed, 05 Oct 2022 09:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mikael Djurfeldt Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 05 Oct 2022 13:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58297 X-GNU-PR-Package: guile Original-Received: via spool by 58297-submit@debbugs.gnu.org id=B58297.166497644224181 (code B ref 58297); Wed, 05 Oct 2022 13:28:02 +0000 Original-Received: (at 58297) by debbugs.gnu.org; 5 Oct 2022 13:27:22 +0000 Original-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 Original-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 Original-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) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.io gmane.lisp.guile.bugs:10396 Archived-At: --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--