[Top][All Lists]

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

Re: subr-x.el code and defsubst [was: Trimming strings, /.../subr-x.el m

From: Tianxiang Xiong
Subject: Re: subr-x.el code and defsubst [was: Trimming strings, /.../subr-x.el modification]
Date: Sun, 14 May 2017 15:45:11 -0700

I also don't understand why `subr-x.el` exists. 

First of all, why not put `string-*` functions in a `string.el`? It's surprising that no such file exists at the moment.

Secondly, why are these functions considered "experimental"? If a package depends on a function in `subr-x` that is later removed, is it any less inconvenient for the package author than if `subr-x` was not experimental? No. Empirically, the `string-*` and `thread-*` functions see a lot of use in the wild, so (re)moving them at this point would cause quite an uproar.

If functions need to considered experimental, at least put them in the "right" place--e.g. `string-empty-p` in `string.el`. That way, even if the function's implementation needed to be modified, package authors won't need to `require` a different package. Organization matters.

On Sat, May 6, 2017 at 11:07 AM, Drew Adams <address@hidden> wrote:
> > The code will be byte-compiled.  I see zero reason why these
> > functions should be defsubsts.
> The reason, AFAIC is the following: subr-x holds functions which we
> haven't committed to adding to core.  We exceptionally allow them to
> not use a prefix but in return we only use subr-x while compiling (since
> it's fundamentally not namespace-clean and we don't want to impose those
> non-clean names upon the unsuspecting user).

OK.  Not a great reason, IMO, but I understand now, at least.

I don't think that reason is obvious.  Please consider adding a
GIANT comment in subr-x.el to explain this exceptional treatment.

This existing comment, which is all there is, does not cover it, IMO:

;; Less commonly used functions that complement basic APIs, often
;; implemented in C code (like hash-tables and strings), and are
;; not eligible for inclusion in subr.el.

;; Do not document these functions in the lispref.
;; http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01006.html

And why is it that this library has still not been "committed to
core"?  (And isn't that what GNU ELPA is for?)

Beyond that, this approach of not bothering with name prefixes,
byte-compiling separately, etc. seems really weird (fragile, error
prone).  Why such an exception?  Is this really the best way to
handle code that you consider "experimental" or "less commonly used"
or code "that complements basic APIs"?

reply via email to

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