Re: Namespaces - summary, conclusion

[ams@gnu.org (Alfred M. Szmidt)]

   >    rename-file -> file-rename
   >    delete-file -> file-delete
   >    copy-file -> file-copy
   >
   > These functions are also interactive, where it is far more 
   > natural to
   > want to rename/delete/copy a file, than ... a file
   > renamed/deleted/copied.
   >  
   >    expand-file-name -> file-expand-name
   >
   > You're expanding a file name, so the name seems to fit the task.

   But wouldn't that be an excellent reason to have an alias?

I think it was mentioned before, but aliases are not without a cost.
They have to be maintained, and there is the cognitive load as well.
The line to draw where one stops adding aliases becomes fuzzy quickly.

Having multiple names for the same thing also reduces discoverability,
since now you have multiple things called similar but possible
different.  And Emacs already provides excellent means to discover
things, as pointed out by Eli several times.

If Emacs was started today from scratch, some of these naming changes
would maybe be a good idea (e.g., file-name-expand
vs. expand-file-name -- neither is a bad name for that particular
function) ... but expand-file-name is as old as Emacs, and as a
function name for what it does it is adequate.

Changing/Adding such a name (or any other name) has to be weighed
against that, and that is very heavy pot of gold.  And I think Eli, et
al want something more than just a list of here are functions that
should change or what ones current preference is... 

Change for changes sake isn't very useful.  Sometimes good enough is
just perfect.