Philippe Vaucher <address@hidden> 작성:
Given this is more or less the position held by Alan, Eli, Richard,
Drew and João I think the chances of seeing new aliases is close to 0.
This is not my conclusion. I've seen several calls to move away from
from discussing in the abstract to discuss specific, concrete
examples. I think this is a good idea, since IMHO the abstract
discussion is likely exhausted.
There is always the chance that some of the proposals will be voted
down. But also consider that some who have disagreed with you in the
abstract might be more convinced by specific, concrete proposals.
So far the string- proposal got shot down entirely. The regexp one was
initially a no-go from Alan but I then Richard kinda liked it and
proposed adaptations.
@Stefan Monnier: I see that you talked about `multibyte-string-p`
already (and iirc that didn't went well. You talked earlier about
`process-`, maybe you'd like to propose some changes there?
I think for people to propose changes and get them adapted, we first have
to
have some proper goals to target.
So there are a few people here who think renaming some functions is
beneficial
- but everybody’s reasoning is different here. Some people who are
opposed to
renaming are a bit confused.
I think the two big goals are consistency and discoverability. And then
there
are various small arguments like it’s easier to use prefix based
completion and
function search, it’s easier to guess, namespace means less function name
clashing, etc…
I think consistency is important, and if the language itself wants naming
things the ‘lisp-way’, I’m fine with a consistent naming scheme. I’m not
sure
if you’d agree or not, but maybe trying to find a consistent naming
scheme and
documenting them (which was called as the ‘lisp-way’ by some) might be
first.
And then we can rename the ones that don’t follow them.
I mean I'm willing to propose concrete changes but if it's not obvious
for string- and regexp- why would it be for other topics? Let's try
another topic just to see:
rename-file -> file-rename
delete-file -> file-delete
copy-file -> file-copy
expand-file-name -> file-expand-name
Do you think people will be ok with that?
The reason why I said about finding the naming scheme was because both the
function name rename-file and file-truename makes sense to me.
I think some preliminary conventions that Elisp already follows is that the
<action>-<object> scheme is for actions on the object like rename-file or
clear-string, and <object>-<property> scheme is for getting properties of
the
object like string-width and file-name-extension. (I’m not considering
polymorphic ones.)
But then there are exceptions, like string-trim (which should then be
trim-string) or string-join (which should then be join-string).
What does everybody think about this? I think it would be less disruptive
and
controversial if some Elisp core API guidelines are decided, written, and
followed in the future. Then, if it turns out it’s useful enough, we can
start
aliasing functions that don’t follow them to names that do follow them (if
it’s desirable to do so.)