From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Foreign object API Date: Thu, 05 Nov 2015 11:16:13 +0100 Message-ID: <87611gah02.fsf_-_@gnu.org> References: <87vb9ihy6x.fsf@igalia.com> <87oaf9zojn.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1446718594 11596 80.91.229.3 (5 Nov 2015 10:16:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Nov 2015 10:16:34 +0000 (UTC) Cc: Andy Wingo , guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Nov 05 11:16:28 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 1ZuHal-0004fh-Gn for guile-devel@m.gmane.org; Thu, 05 Nov 2015 11:16:27 +0100 Original-Received: from localhost ([::1]:59597 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuHak-0008Ny-SY for guile-devel@m.gmane.org; Thu, 05 Nov 2015 05:16:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuHaf-0008NX-Ld for guile-devel@gnu.org; Thu, 05 Nov 2015 05:16:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuHab-00035Y-Jt for guile-devel@gnu.org; Thu, 05 Nov 2015 05:16:21 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuHab-00035U-H5; Thu, 05 Nov 2015 05:16:17 -0500 Original-Received: from pluto.bordeaux.inria.fr ([193.50.110.57]:36400 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZuHaa-0006xI-Md; Thu, 05 Nov 2015 05:16:17 -0500 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 15 Brumaire an 224 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x3D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87oaf9zojn.fsf@netris.org> (Mark H. Weaver's message of "Wed, 04 Nov 2015 12:01:48 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:17980 Archived-At: Mark H Weaver skribis: > Deprecating and replacing the SMOB API is a significant event in the > history of Guile. It should not be rushed, nor should it be finalized > until it supports existing use cases and anticipated future > developments. Agreed. > As an aside, I'm not happy with the fact that this new foreign objects > API was pushed to the stable-2.0 branch less than 25 hours after the > initial proposal was posted. It feels like establishing "facts on the > ground", and sets up a situation where the burden is now on me to argue > that it's not ready to be included in 2.0.12, whereas the burden should > rather be on you to obtain a consensus that this new major API is ready > for release. Agreed too. But we had already agreed on both long ago. :-) > For now, I would prefer to revert the commits that added this new API, > to enable the immediate release of 2.0.12. Then we can have a proper > discussion about what a SMOB replacement API should look like, and make > sure that both past and future anticipated use cases are covered before > releasing it. I sympathize with your concerns. (I wish we had had this discussion long ago, when Andy pushed the foreign objects API, or when I called for us to =E2=80=9Cdo something=E2=80=9D about it so we can release 2.0.12.) Could you summarize your practical concerns with the foreign object API so we can decide whether reverting is the best thing to do to move forward? I expressed mine in to which Andy replied on IRC the other day that (roughly; correct me if I=E2=80=99m wrong): 1. GOOPS is faster in 2.1. 2. In 2.4 we may be able to avoid loading GOOPS altogether, but not before that. 3. It=E2=80=99s OK if foreign objects introduce some overhead compared to SMOBs in 2.0, because the addition of this API in 2.0 is for people who want to write forward-compatible code where overhead is less of an issue. 4. Even though some primitives are turned into primitive-generics, there are no observable semantic differences when GOOPS is loaded. 5. Using structs as I suggested above appears to be undoable for obscure reasons. I am not fully convinced, but I prefer to live with that than with a frozen project. Besides, it is clear to me that the SMOB API is here to stay, as is, in the 2.2 series and probably the 2.4 series as well. I believe Andy agrees with that. Don=E2=80=99t escape this thread people, you=E2=80=99re trapped! :-) Thanks, Ludo=E2=80=99.