Re: Namespaces - summary, conclusion

[조성빈 <pcr910303@icloud.com>]

조성빈 <pcr910303@icloud.com> 작성:

> Philippe Vaucher <philippe.vaucher@gmail.com> 작성:
>
>>>> 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.)

I’ve CCed some Elisp users that I think would have some knowledge and  
opinions
about this - can people dial in and codify the ‘lisp-way’ or the ‘elisp-way’
so that we can have some starting point of the API guidelines?

(If someone is opposed to making an API guideline, can somebody explain the
  reasons too?)