Re: helpers.el [was: ... lisp/emacs-lisp/helpers.el...]

[Bozhidar Batsov <bozhidar@batsov.com>]

[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]

On 30 November 2013 01:50, Drew Adams <drew.adams@oracle.com> wrote:

> FWIW -
>
> `helpers.el' is an *un*helpful file name.
>
> It is bad enough that we already have a file `helper.el' in
> the same directory.  Even for that file the name is not so
> useful, but at least that is about providing "help in electric
> modes".  (Something like `elec-help.el' would have been better.)
>

Yeah, ele-help would have been a better name.


>
> Please consider coming up with something better than "helpers".
>

We were a bit short on ideas - the alternative were "one-liners",
"misc-helpers", "misc-utils", etc.
Suggestions for a better name are welcome.


>
> Especially since `helpers.el' is purportedly "Some non-essential
> library extensions."  Library extensions?  What library is
> extended?  If not a library, what is extended by this code?
>

Assuming we can say we have a "string" library and a "hash" library, I'd
say currently "helpers" have extensions for them.


>
> Non-essential is right, however.  This file has 7 one-liner
> defsubsts in it - nothing more.  Now maybe big things are
> expected for this little file in the future, but even then I'd
> suggest that, at least for now, these functions be put
> somewhere else.
>

Stefan mentioned that we wants to move many *defsubst*s to a common library
at some point.
As far as I'm concerned I would have preferred to have the currently
present functions in a place like `subr.el`, since I'm pretty sure of the
usefulness
of those "non-essential" functions.


>
> Where to put such things, if not in a dedicated trifles bag?
> Put similar things together (and not just similar by being tiny).
>

I guess we can have separate helper libs - something like *string-ext*,
*hash-ext*, etc.
This is fine by me.


>
> And if the intention is to progressively pick up other such
> functions from other files and toss them in `helpers.el', so
> that it becomes a growing catch-all, then I'd recommend to
> think twice about that project.
>
> But if you really cannot do any better than create a grab bag,
> then please at least give it a name that reflects that failure
> and does not lead to more confusion.
>

I'd argue that several existing libraries exhibit the same problem (most
notably - subr.el). Maybe we should try
harder to arrange related code together in the future.

[-- Attachment #2: Type: text/html, Size: 3774 bytes --]