From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bozhidar Batsov Newsgroups: gmane.emacs.devel Subject: Re: helpers.el [was: ... lisp/emacs-lisp/helpers.el...] Date: Sat, 30 Nov 2013 09:41:38 +0200 Message-ID: References: <946783d5-d410-4ee8-87c8-20a2e80258e5@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d0444eb29bdbc7e04ec6013db X-Trace: ger.gmane.org 1385797299 6980 80.91.229.3 (30 Nov 2013 07:41:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Nov 2013 07:41:39 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 30 08:41:45 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VmfBR-0004Ai-3R for ged-emacs-devel@m.gmane.org; Sat, 30 Nov 2013 08:41:45 +0100 Original-Received: from localhost ([::1]:51171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmfBQ-0003Ew-LM for ged-emacs-devel@m.gmane.org; Sat, 30 Nov 2013 02:41:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmfBN-0003Ep-6b for emacs-devel@gnu.org; Sat, 30 Nov 2013 02:41:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VmfBL-0003RD-TO for emacs-devel@gnu.org; Sat, 30 Nov 2013 02:41:41 -0500 Original-Received: from mail-oa0-x22f.google.com ([2607:f8b0:4003:c02::22f]:61725) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmfBL-0003R7-ME for emacs-devel@gnu.org; Sat, 30 Nov 2013 02:41:39 -0500 Original-Received: by mail-oa0-f47.google.com with SMTP id k1so11054837oag.6 for ; Fri, 29 Nov 2013 23:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QWG7yG9Lz6UUUR05OWmn7MxpW01RAxdGFD6L2rob3UI=; b=qrxBAE5+A+x+tfwd15F/smFmYaaUhn+X/Rwr7U019dExPgAk1dIFK7FIDSZLQxxBcX 7QiUgN+EcWFkxozKzDIc+pClx78aB+whCtaytJTsHr4E0jxqeyALJAD9exO9XQVZh9V1 OfPIiFchMFPeUdUTQ20mO5etB/qVOmDbBMH1UtK5dgaxC5k4chP6I5ZM5N2U1TTdd5kA 9uEWeKv4RA3HIG3gp17MwvnzZwEyKPU4D5Tdxg+i+bxvLLu7YU+bBHlQfNFxVYKP1qVA LHJ7MorYSxh2FWbCeTbxiC1GsuLna1/PMhkO8cxilf8TfsEbjTD5e4AYMiaqLjS9iRO2 aLag== X-Received: by 10.182.194.5 with SMTP id hs5mr15877825obc.19.1385797299058; Fri, 29 Nov 2013 23:41:39 -0800 (PST) Original-Received: by 10.76.175.102 with HTTP; Fri, 29 Nov 2013 23:41:38 -0800 (PST) In-Reply-To: <946783d5-d410-4ee8-87c8-20a2e80258e5@default> X-Google-Sender-Auth: xsQf-coHfWjcSr2jawIFFO1ze_0 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:165926 Archived-At: --f46d0444eb29bdbc7e04ec6013db Content-Type: text/plain; charset=UTF-8 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. --f46d0444eb29bdbc7e04ec6013db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 30 November 2013 01:50, Drew Adams &l= t;drew.adams@ora= cle.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. =C2=A0Even for that file the name is not so
useful, but at least that is about providing "help in electric
modes". =C2=A0(Something like `elec-help.el' would have been bette= r.)

Yeah, ele-help would have been a be= tter name.
=C2=A0

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

We were a bit short on ideas - the alter= native were "one-liners", "misc-helpers", "misc-ut= ils", etc.=C2=A0
Suggestions for a better name are welcome.
=C2=A0

Especially since `helpers.el' is purportedly "Some non-essential library extensions." =C2=A0Library extensions? =C2=A0What library is extended? =C2=A0If 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.
=C2=A0

Non-essential is right, however. =C2=A0This file has 7 one-liner
defsubsts in it - nothing more. =C2=A0Now 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 w= e wants to move many *defsubst*s to a common library at some point.=C2=A0
As far as I'm concerned I would have preferred to have the cur= rently present functions in a place like `subr.el`, since I'm pretty su= re of the usefulness
of those "non-essential" functions.=C2=A0
=C2=A0

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 - somet= hing like *string-ext*, *hash-ext*, etc.=C2=A0
This is fine by me= .
=C2=A0

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 re= lated code together in the future.

--f46d0444eb29bdbc7e04ec6013db--