From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Pirotte Newsgroups: gmane.lisp.guile.devel Subject: Re: goops - guile-clutter unexpected bug while using #:virtual slot allocation for a subclass Date: Sat, 7 Feb 2015 15:13:51 -0200 Message-ID: <20150207151351.57b98221@capac> References: <20141219174633.6efb845e@capac> <8761btfcni.fsf@pobox.com> <20150126230044.2d1e71de@capac> <87sieweie4.fsf@pobox.com> <20150127171115.6172ccea@capac> <87zj94c5rv.fsf@pobox.com> <20150130115015.5c8e3192@capac> <878ugb9nbk.fsf@pobox.com> <20150206150933.09e166f6@capac> <87a90r7wwr.fsf@pobox.com> <20150206220637.310db45e@capac> <87oap57mwi.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/=fgT.2TxElq9OLsfBF6wShO"; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1423329271 5923 80.91.229.3 (7 Feb 2015 17:14:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Feb 2015 17:14:31 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Feb 07 18:14:30 2015 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YK8xh-0002Rb-VQ for guile-devel@m.gmane.org; Sat, 07 Feb 2015 18:14:30 +0100 Original-Received: from localhost ([::1]:53892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK8xh-0008OR-7k for guile-devel@m.gmane.org; Sat, 07 Feb 2015 12:14:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK8xe-0008NV-Fz for guile-devel@gnu.org; Sat, 07 Feb 2015 12:14:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YK8xa-0003xr-UA for guile-devel@gnu.org; Sat, 07 Feb 2015 12:14:26 -0500 Original-Received: from maximusconfessor.all2all.org ([79.99.200.102]:52208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YK8xa-0003s4-MW for guile-devel@gnu.org; Sat, 07 Feb 2015 12:14:22 -0500 Original-Received: from localhost (unknown [192.168.0.2]) by maximusconfessor.all2all.org (Postfix) with ESMTP id E66EDA04C106; Sat, 7 Feb 2015 18:14:00 +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 qSjFJIuBabX6; Sat, 7 Feb 2015 18:13:54 +0100 (CET) Original-Received: from capac (unknown [179.210.40.117]) by maximusconfessor.all2all.org (Postfix) with ESMTPSA id 450C0A04C0F4; Sat, 7 Feb 2015 18:13:53 +0100 (CET) In-Reply-To: <87oap57mwi.fsf@pobox.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 79.99.200.102 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17656 Archived-At: --Sig_/=fgT.2TxElq9OLsfBF6wShO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > Hello again :) Yes, hello, Saturday greetings! > ... So let us not argue over that. Let us instead treat your concern as = request > that the behavior should be different. Perfect, let's talk about ... should we, how, how much :) ... =20 > > we should follow the clos spec here > That said I think the CLOS way is usually better Agreed, definitely: I'm well aware that it is a very complex task to imple= ment it correctly [and fully, but I don't need the full protocol either, 1 day mayb= e...], and very 'frustrating' too, since it is almost impossible to make it run 'fast'= , by definition, as you know. of course ... But I really need the subset we have= in goops to implement the corresponding clos subset protocol, especially what we are= talking about. > but we are limited by two things: compatibility with past behavior (not a > terrible concern in this instance, given the lack of outcry when I broke = things), > and secondly by hack-power. In particular I do not have any additional f= ree > time to spend on GOOPS features in the near future. Would you have some available pay time? If so, could you send me a private = quote, I need this change asap, and if the quote is reasonable, you could start imme= diately. If you [guilers] think it should also be in goops, fine, I am happy to 'fund that part of the protocol for all' :) If not, could you include in the quo= te a bit of time to implement a git branch with goops only, name it gclos or wha= t ever is [more] appropriate , if that is possible [?], so that I can always and i= n a very easy way, track stable-2 [master in the near future] but apply 'my' goops [I mjean (re)configure/make/make install 'my' goops... > This feature you are asking for requires: >=20 > * more logic in method-applicable? for accessor methods that would > 1. check the list of effective slot definitions in the target object > 2. for each slot, get the direct slot definition > - currently there is no long from effective to direct, we'd have > to add that > 3. if the target object has a slot with the same direct slot > definition as the one associated with the accessor method, then > the method applies, otherwise not >=20 > * compile-time specialization for methods, as in > 583a23bf104c84d9617222856e188f3f3af4934d which was later reverted >=20 > Open questions would be, do we expose method-applicable? as a generic, > there's some gnarly circularity because these methods are part of the > method dispatch protocol, do we expose more of the slot protocol to > users (it's currently somewhat opaque and unfinished), how to document > all of this, we need a bunch of tests too, how do you relate effective > slots to direct slots in the CLOS case where you can make composite > slots, etc. I will answer this part a bit latter, I need to think about it :) > It's a bit of work and I need to do other things :) Sure, I have too,=20 Let's see if you are interested and has pay time available... Cheers, David --Sig_/=fgT.2TxElq9OLsfBF6wShO Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU1kfPAAoJEPN0/ZOjBXrXKfMH/jeK5UtHbBKJu2w/HVr9CnSG fCkvau8bGJUhfxUM5NQfJuyltBR4Rws5OnOGxF4F0uaVthC1e14oEglY4XQDyocV bBZdIs/0l8Vul893h8UfSielobmhGFv/aRydVGPhkwlqaVL+KGtckkHDJPmq3f/p 5dFqYMNmSjXbajI1v8V38pzXj2dkcCNBB+vdA2qN7l97l0KzXpq1B6snSrmjnukD R7AhVEy8XOjP/1ap3ccHjUjNGL7LFdvhvlG9cBFjxr4zjG0dmn9LhdQbISBTpwcz PFIZUcQ5GOfjDQtOIczS4/A80dzVjhxN+3g4NMhLxJqCOISK1El6BGDQM29kgVs= =5CPf -----END PGP SIGNATURE----- --Sig_/=fgT.2TxElq9OLsfBF6wShO--