[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trunk r115926: In preparation for the move to git, sanitize out some

From: Eric S. Raymond
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
User-agent: Mutt/1.5.21 (2010-09-15)

Juanma Barranquero <address@hidden>:
> On Thu, Jan 9, 2014 at 2:13 PM, Eric S. Raymond <address@hidden> 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.
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]