From: John Wiegley <jwiegley@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
emacs-devel@gnu.org, tino.calancha@gmail.com
Subject: Re: naming functions [was: Ibuffer: w and B default to buffer at current line]
Date: Sun, 18 Sep 2016 12:23:33 -0700 [thread overview]
Message-ID: <m2twddqafe.fsf@newartisans.com> (raw)
In-Reply-To: <054178e6-00ee-48ec-8799-3845c79675cd@default> (Drew Adams's message of "Sun, 18 Sep 2016 10:55:30 -0700 (PDT)")
[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]
>>>>> Drew Adams <drew.adams@oracle.com> writes:
> Is `forward-char' a bad name, because with a negative prefix arg it moves
> backward? Is it a bad name because it is singular and a prefix arg > 1 moves
> further than one position?
> Should the name have been `move-char' or `move-chars'? If so, then what
> about binding forward and backward default behaviors to different keys,
> `C-f' and `C-b'?
> I think (hope) you get the point. A function name only goes so far toward
> indicating what the function does. If a prefix arg to a command chooses
> alternative behavior, then it would often be cumbersome and _less_ clear to
> users, to use a name that tries to summarize all of the behaviors.
The only point I'm seeing here is that we've been imprecise with our function
names in the past. That is not a valid argument for how we should assess
patches in the future.
Yes, `forward-char' is misleading. `move-point' might have been a better
choice. But there are many ships like this that left the port long ago. I'm
not even suggesting we retroactively fix any of them. What I will do, however,
is reject the belief that because it happened in the past, this makes it OK to
extend existing functions like this for the sake of expediency.
So unless you're actually arguing for it to be OK to extend functions beyond
their stated semantics, I hope we can agree on the essential point here: don't
pollute the behavior of functions because it's easy to do so. With just a bit
of extra work, we can avoid unnecessarily increasing our technical debt.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]
next prev parent reply other threads:[~2016-09-18 19:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 5:35 Ibuffer: w and B default to buffer at current line Tino Calancha
2016-09-14 6:41 ` John Wiegley
2016-09-14 7:21 ` Tino Calancha
2016-09-14 14:08 ` Drew Adams
2016-09-15 22:05 ` John Wiegley
2016-09-16 6:40 ` Eli Zaretskii
[not found] ` <<83intw5our.fsf@gnu.org>
2016-09-16 14:53 ` Drew Adams
2016-09-17 16:30 ` John Wiegley
2016-09-17 17:21 ` Eli Zaretskii
2016-09-17 21:35 ` John Wiegley
2016-09-17 23:26 ` Drew Adams
2016-09-17 23:51 ` John Wiegley
2016-09-18 1:45 ` Drew Adams
2016-09-18 2:18 ` John Wiegley
2016-09-18 14:26 ` Eli Zaretskii
2016-09-18 19:35 ` John Wiegley
[not found] ` <<83zin630i9.fsf@gnu.org>
2016-09-17 18:47 ` Drew Adams
2016-09-17 19:25 ` Eli Zaretskii
[not found] ` <<83vaxuib1p.fsf@gnu.org>
2016-09-17 19:33 ` Drew Adams
2016-09-18 14:29 ` Eli Zaretskii
[not found] ` <<d33a60f5-b8b6-4637-b3e6-ea1b09d98f85@default>
[not found] ` <<83poo1i8nf.fsf@gnu.org>
2016-09-18 17:55 ` naming functions [was: Ibuffer: w and B default to buffer at current line] Drew Adams
2016-09-18 19:23 ` John Wiegley [this message]
2016-09-18 23:24 ` Drew Adams
2016-09-19 16:35 ` Eli Zaretskii
2016-09-17 18:22 ` Ibuffer: w and B default to buffer at current line Tino Calancha
2016-09-26 12:08 ` Tino Calancha
2016-10-03 12:28 ` Tino Calancha
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2twddqafe.fsf@newartisans.com \
--to=jwiegley@gmail.com \
--cc=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=tino.calancha@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.