From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Wed, 18 Feb 2015 09:55:07 +0900 Message-ID: <87sie4ghsk.fsf@uwakimon.sk.tsukuba.ac.jp> References: <838ugdf251.fsf@gnu.org> <87bnl1vmqf.fsf@lifelogs.com> <87vbj8tow4.fsf@lifelogs.com> <87r3twtagf.fsf@lifelogs.com> <85siebl7ws.fsf@stephe-leake.org> <85a90ilwmm.fsf@stephe-leake.org> <83386a6f7z.fsf@gnu.org> <85h9upjz7v.fsf@stephe-leake.org> <83wq3k3kl4.fsf@gnu.org> <85bnkwil1c.fsf@stephe-leake.org> <83pp9cwky8.fsf@gnu.org> <85a90ggf2d.fsf@stephe-leake.org> <54E0A40F.5080603@dancol.org> <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@87.69.4.28> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <833865vp4d.fsf@gnu.org> <54E2355A.90@87.69.4.28> <83vbj1u020.fsf@gnu.org> <54E24CA4.9020601@dancol.org> <83h9uk7ddb.fsf@gnu.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 1424220958 24984 80.91.229.3 (18 Feb 2015 00:55:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Feb 2015 00:55:58 +0000 (UTC) Cc: Eli Zaretskii , Daniel Colascione , Stephen Leake , Emacs development discussions To: =?utf-8?Q?Aur=C3=A9lien?= Aptel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 18 01:55:49 2015 Return-path: Envelope-to: ged-emacs-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 1YNsvb-00028j-Qj for ged-emacs-devel@m.gmane.org; Wed, 18 Feb 2015 01:55:47 +0100 Original-Received: from localhost ([::1]:47950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNsvb-0006eK-Bl for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2015 19:55:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNsvH-0006e9-Eu for emacs-devel@gnu.org; Tue, 17 Feb 2015 19:55:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNsvF-0005Ak-Vq for emacs-devel@gnu.org; Tue, 17 Feb 2015 19:55:27 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:38594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNsvC-000581-6Y; Tue, 17 Feb 2015 19:55:22 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 3A79C1C387E; Wed, 18 Feb 2015 09:55:07 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 22F511A26E3; Wed, 18 Feb 2015 09:55:07 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183221 Archived-At: Aur=C3=A9lien Aptel writes: > I'm with Eli on the versionning choice Versioning is a poor choice here for the same reasons it almost always is. Dan's design means that the module doesn't need to care about the implementation, except for the usual reasons of breaking promises about semantics. It's equivalent to the recommended design of using feature tests rather than version tests. > but it's just bike shedding at this point. With Dan's design, there's nothing left *but* bikeshedding, Brother Aur=C3=A9lien. It solves problems I didn't know XEmacs's design has. > Interning all the time seems tedious and probably (a bit?) slow but > moving the interning on Emacs side won't change the slow part. It's not detectably slow, especially if you cache the result, and the intern-and-cache process can be performed by a macro in module_api.h or by a function exported from Emacs. A little bit of elisp for collecting and decorating the names you need in a module init function, and it's bearable tedium. This is based on a decade and a half of experience with XEmacs's "ELL" module system. > At least on the module side you can do it once and reuse the > result. Or maybe you shouldn't if the user changes the binding in > the meantime? I'm not sure about Dan's "one more indirection" design, but in the case where you use the result of intern directly, this has the expected semantics: the user's change wins. Dan's design should have the same semantics, I'm guessing.