Re: Namespaces - summary, conclusion

[조성빈]

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.)

> Philippe