From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: trunk r115926: In preparation for the move to git, sanitize out some Bazaar-specific names. Date: Thu, 9 Jan 2014 08:47:16 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20140109134716.GA6290@thyrsus.com> References: <20140109012554.GA23333@thyrsus.com> <20140109052705.GA3424@thyrsus.com> <20140109123702.GB5361@thyrsus.com> <20140109131337.GA6053@thyrsus.com> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1389275251 4678 80.91.229.3 (9 Jan 2014 13:47:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 13:47:31 +0000 (UTC) Cc: Bastien , Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 09 14:47:39 2014 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 1W1FxS-0005OA-JE for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 14:47:38 +0100 Original-Received: from localhost ([::1]:52015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1FxS-0006YK-7a for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 08:47:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33858) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1FxL-0006YA-8D for emacs-devel@gnu.org; Thu, 09 Jan 2014 08:47:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1FxG-0002Mg-FQ for emacs-devel@gnu.org; Thu, 09 Jan 2014 08:47:31 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:38089 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Fx7-0002L4-I2; Thu, 09 Jan 2014 08:47:18 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 9F47F380496; Thu, 9 Jan 2014 08:47:16 -0500 (EST) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 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:167904 Archived-At: Juanma Barranquero : > On Thu, Jan 9, 2014 at 2:13 PM, Eric S. Raymond wrote: > > > Wouldn't defining emacs-bzr-get-version as an obsolete function alias > > for emacs-repository-get-version solve the problem in a way > > satisfactory to both of us? > > Sorry, no. It is not compatible. Code has been written that > understands the case that emacs-bzr-version isn't bound, or bound and > nil, or bound and meaningful (with structure). That code will have to > be changed if you insist in conflating it with your higher-level API > which IMO is not really a new layer (Emacs is not going to have to > deal with several underlying DVCS at once in its repository, as you > said yourself a few messages ago; DVCS-specific functions and > variables are not only not a bug, but a feature). > > > It wouldn't reintroduce a layering bug into loadup.el, and it would give you > > your compatible API. > > Even accepting that it is a layering bug (which I don't), there's no > problem in keeping it in loadup.el; that's why we have > make-obsolete(-variable). We don't need to clean up in a hurry every > possible clue of past mistakes; just fix the mistakes. And, as said, > what you offer is not compatible. emacs-repository-version is not > compatible with emacs-bzr-version; the structure was documented, it > never was a magical, opaque cookie. > > J The more you talk about this, the less you're making any sense to me. All this about the return value having structure is a red herring. You still *get* that structure by looking at emacs-bzr-version. I have not changed that and will not; only the VCS transition will do that. Similarly, the unbound and bound-but-nil cases will still work; that's the point of declaring an alias, isn't it? With both the variable and function alias in place, I don't understand what code would need to be changed. Show me. -- Eric S. Raymond