On 30 November 2013 01:50, Drew Adams 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.