unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Robert Pluim <rpluim@gmail.com>, Lars Ingebrigtsen <larsi@gnus.org>
Cc: emacs-devel@gnu.org
Subject: RE: master baf331e 3/3: Rename replace-in-string to string-replace
Date: Mon, 28 Sep 2020 08:21:03 -0700 (PDT)	[thread overview]
Message-ID: <9e0ee248-a276-4f6a-a29f-a8984a0cf6fa@default> (raw)
In-Reply-To: <m2sgb2ytuv.fsf@gmail.com>

>  >> Do we need a (defalias 'string-replace-regexp
>  >> 'replace-regexp-in-string)?
> 
>  Lars> I'm not very enthusiastic about adding noun-verb aliases for the
>  Lars> verb-noun functions we already have.  It makes reading code more
>  Lars> confusing when we have several names for the same thing.
> 
> I agree, but in this case anyone who finds 'string-replace' is going
> to have a harder time finding 'replace-regexp-in-string'. The two
> functions are twins, they should be easy to find from one another.
> 
>  Lars> Discoverability is an issue, though, and I'm working on that.
> 
> We can always stick cross-references in the respective docstring, but
> people are still going to wonder about the irregular naming.


FWIW - two things to say here, one about the name
`string-replace' and one, more general, about naming.


1. `replace-in-string' is pretty self-explanatory,
certainly more so than `string-replace'.  The latter
makes you think that you're replacing one string with
another (which you are) - but where?  In a buffer? file?
the region?

`string-replace' suggests the same that `replace-string'
suggests.  And we already have `replace-string':
"Replace occurrences of FROM-STRING with TO-STRING."
Now we'll have `replace-string' and `string-replace'?
Is that progress?

IIUC, `replace-in-string' was rejected because of some
incompatibility with XEmacs (name clash?).  If so,
that's too bad, as replacing something within a string
is pretty clear from that name.  And as the something
isn't part in the name, it's pretty straightforward to
guess that it's a substring that's being replaced.

Both `replace-in-string' and `replace-regexp-in-string'
are pretty clear.  `string-replace' and
`string-replace-regexp' not so much.

Just sayin'.  I don't really have a great alternative
here.  (`replace-substring'? `replace-within-string'?
`replace-some-of-string'? `replace-string-substring'?)
If `replace-in-string' is off limits for some reason
then so be it - but too bad.


2. Discoverability is important, yes - very important.
But it's a mistake, IMO, to sacrifice more easily
understood names in favor of less easily understood
names, only because of easier discoverability by
_prefix completion_.  (Again, general argument here -
not about `string-replace'.)

Better to improve completion (use substring or regexp
or fuzzy or ... completion) so that the better names
are more easily discovered using completion.

_Apropos_ should be our guide for discoverability, not
prefix completion.  Our UI (especially completion)
should make it easy to discover a name by its
"components", in whatever order they might appear.

[I have a lot of experience with "apropos" completion,
including ways to match name components/substrings in
arbitrary order.  That's lacking in vanilla Emacs.]

We should not name things with discovery by prefix
completion foremost in mind.  That's a step backward.
If all other things are equal (rare), prefix-oriented
discovery can be nice to have - nothing more.

This point (#2) is not about _what can make_ a name
more understandable.  (There are lots of things to
consider for that.) 

And this point isn't an argument favoring noun-verb
or verb-noun.  This is only to favor understandable
names (however that's judged), and to deal with
discoverability separately, rather than elevating
prefix-completion discoverability as an important
criterion for naming.

And this point says nothing about the value of
naming _consistency_.  That's a different, but
related, topic.



  reply	other threads:[~2020-09-28 15:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200926222500.20662.9159@vcs0.savannah.gnu.org>
     [not found] ` <20200926222503.227F720441@vcs0.savannah.gnu.org>
2020-09-28  9:32   ` master baf331e 3/3: Rename replace-in-string to string-replace Robert Pluim
2020-09-28 11:14     ` Lars Ingebrigtsen
2020-09-28 12:21       ` Robert Pluim
2020-09-28 15:21         ` Drew Adams [this message]
2020-09-28 15:42           ` Robert Pluim
2020-09-28 16:28             ` Mattias Engdegård
2020-09-28 16:31             ` tomas
2020-09-28 17:21           ` Stefan Monnier
2020-09-28 17:30             ` Drew Adams
2020-09-29 13:29             ` Lars Ingebrigtsen
2020-09-28 13:45       ` Stefan Monnier
2020-09-28 14:01         ` Lars Ingebrigtsen
2020-09-28 14:56     ` Stefan Kangas
2020-09-28 15:25       ` Robert Pluim
2020-09-28 15:41         ` Drew Adams
2020-09-28 15:45           ` Robert Pluim
2020-09-28 16:01             ` Drew Adams
2020-09-28 15:38       ` Drew Adams
2020-09-28 15:50         ` Robert Pluim
2020-09-28 16:03           ` Drew Adams
2020-09-28 15:44       ` Lars Ingebrigtsen
2020-09-29 13:22         ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e0ee248-a276-4f6a-a29f-a8984a0cf6fa@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --cc=rpluim@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).