emacs-devel
[Top][All Lists]
Advanced

[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: Drew Adams
Subject: RE: subr-x.el code and defsubst [was: Trimming strings, /.../subr-x.el modification]
Date: Sun, 14 May 2017 18:11:37 -0700 (PDT)

> 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.

FWIW, I agree.

Perhaps it's not a coincidence that this policy/approach was
accompanied in time by the introduction (or perhaps increase)
of the use of "*--*" names for "internal" Lisp constructs.
Similarly misguided, I think.

If you really feel the need for a "purgatory" or "lab" for
code that you don't yet feel confident about or haven't yet
consecrated as official or backed by commitment, code that
you consider experimental or internal so that you can feel
more freedom to modify it without worrying about users, at
least stick it in GNU ELPA, please.



reply via email to

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