From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: David Pirotte Newsgroups: gmane.lisp.guile.devel Subject: Re: Guile-2.2 - goops setters should be inherited, no matter what :) Date: Fri, 17 Mar 2017 05:46:18 -0300 Message-ID: <20170317054455.2419fa9d@capac> References: <20170226195558.764caaa5@capac> <87zigo6o8s.fsf@pobox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/vgtMZFff+Wefa_L6fWb_dhM"; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1489740814 17531 195.159.176.226 (17 Mar 2017 08:53:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 17 Mar 2017 08:53:34 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Mar 17 09:53:26 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1condV-0003VI-KS for guile-devel@m.gmane.org; Fri, 17 Mar 2017 09:53:25 +0100 Original-Received: from localhost ([::1]:47753 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1condb-0001lM-ET for guile-devel@m.gmane.org; Fri, 17 Mar 2017 04:53:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1condT-0001lE-VY for guile-devel@gnu.org; Fri, 17 Mar 2017 04:53:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1condP-0006v1-0J for guile-devel@gnu.org; Fri, 17 Mar 2017 04:53:24 -0400 Original-Received: from maximusconfessor.all2all.org ([79.99.200.102]:48849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1condO-0006q2-Lu for guile-devel@gnu.org; Fri, 17 Mar 2017 04:53:18 -0400 Original-Received: from localhost (unknown [192.168.0.2]) by maximusconfessor.all2all.org (Postfix) with ESMTP id 1936EA04C2A9; Fri, 17 Mar 2017 09:48:51 +0100 (CET) Original-Received: from maximusconfessor.all2all.org ([192.168.0.1]) by localhost (maximusconfessor.all2all.org [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id Gx2vAchXppq1; Fri, 17 Mar 2017 09:48:45 +0100 (CET) Original-Received: from capac (unknown [179.210.17.243]) by maximusconfessor.all2all.org (Postfix) with ESMTPSA id 5AC6FA04C1C6; Fri, 17 Mar 2017 09:46:22 +0100 (CET) In-Reply-To: <87zigo6o8s.fsf@pobox.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x [fuzzy] X-Received-From: 79.99.200.102 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19064 Archived-At: --Sig_/vgtMZFff+Wefa_L6fWb_dhM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello Andy, > > 1- setters, as in (define-method ((setter ...) (self <...>) ...) ...) > > should (also :)) be inherited > As you mention this is https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D19= 770. Yep, but after carefully (re)reading your answer and the manual, doing some= more tests, I came to the conclusion stated in my message (the newly sent messag= e), which in summary says: our documentation says it will create the accessor, unless already created =3D> this, to me, means that: (a) if the expansion code creates the accessor, it should be possible for users to use it on both and instances; (b) from the text of the manual itself, the user should be able to create the accessor him/herself, then redefine the (setter foo) method _without_ altering any semantic wrt to the situation users faces when they are in the (a) situation In other words, once a user defines a setter, both the setter and getter (a= uto created or not) should be available upon the class they belong to and all s= ubclasses > I think we have an understanding about why things are the way they are > in GOOPS ... Good! And I understand you mostly have, if ot entirely inherited and not r= edefined the :) > In this case though I don't know how to make a consistent system with > the semantics you are looking for and without losing some of the speed > of the current system. I'm sorry to hear that, but then we should change the manual, since goops d= oes not implement what is described...=20 note that on a semantic ground, it does not make much sense to define a setter upon a inexistent 'variable location', so, to me, it makes more sense to implement what the manual says; I would definitely not consider speed here, not again semantic anyway, but instead implement what the manual says, maybe with a special note in the manual to explain, if there is?, a way to achieve the same result with bet= ter speed... (like using #:getter then define-method (setter foo) ... ?) > In short I think I just don't agree with this change as part of standard > GOOPS, so I propose the second solution: to make sure you can implement > the behavior you want as a user. What about using a wrapper define-class= macro > that removes "#:accessor foo" from its slot definitions and translates th= ose to > issue definitions like this: >=20 > (define-method (foo (x )) (slot-ref x 'foo)) > (define-method ((setter foo) (x ) val) (slot-set! x 'foo val)) Sure. Do you mean making such a wrapper available in 2.2.x (as opposed to = each of us would have to write his own? By the way that is exactly what the clos protocol says defclass should be e= xpanded to when using :accessor, see [2] for an sbcl session upon the same 'case' (= adapted for syntax and argument order (setf method first argument _must_ be the val= ue ...)) just in case you'd like to play with again, I have made the example code e= ven simpler see [1] (comment/uncomment the definition of the slot with/without the #:accessor and reload, to see how guile 'behaves' in both case... To make it short :):), I'm fine to use the second solution, though allow me= to insist upon the fact that it is 'weird', to me, that the actual implementat= ion properly inherits the setter if the user does not define the accessor, but = then there is no getter, and if the user defines the accessor, then the setter i= s not inherited anymore. Cheers, David [1] (define-class () (width #:accessor width #:init-value 0) #;(width #:init-value 0)) (define-method ((setter width) (self ) val) ;; here comes complex code, computing earth orbit, captain's age... (pk "this is !width setter method, hello!") (slot-set! self 'width val) val) (define-class ()) (define a1 (make )) (define b1 (make )) (set! (width a1) 10) (width a1) (set! (width b1) 10) (width b1) [2] (defclass () ((width :accessor width :initform 0))) (defmethod (setf width) (val (self )) ;; here comes complex code, computing earth orbit, captain's age... (format t "this is (setf width) method, hello!") (setf (slot-value self 'width) val) val) (defclass () ()) (defvar a1 (make-instance ')) (defvar b1 (make-instance ')) =3D> * (setf (width a1) 10) this is (setf width) method, hello! 10 * (width a1) 10 * (setf (width b1) 10) this is (setf width) method, hello! 10 * (width b1) 10 *=20 --Sig_/vgtMZFff+Wefa_L6fWb_dhM Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhCJlRZtBM3furJHe83T9k6MFetcFAljLoloACgkQ83T9k6MF etcegQgAu8TpS0psko6UwTA+AX3WyQkgB81qIcm9b5qCqIo4qJvhL93ZAGc7xqKw ISU3umbymzG561SG/Akq3kBPdDOONlIA+ufYxfckyUWtbdaa8p9Ya3w2ZcYPcqEV 8VAfTcAUGdPb5pcRp+Dp5yla/bB3/6TIVxxJEZO7yTrXh3WcnGfP5VfZFr7q6jsQ xuXcTLxp4yh+Yynldqb9IfaQXTWZexf90UEotTemBU4ZJjYFpokaZFN2kdEc5mSZ dSOaLoClvbnb8nGN5DGGCmWIDFbzX+ll3s0n/NoqN4lY0q8wbMYsKf7y8PBcuJ5i 5LU50FCyrEd9nCTfk4F/H5ERBPGQMg== =YmaW -----END PGP SIGNATURE----- --Sig_/vgtMZFff+Wefa_L6fWb_dhM--