Beman Dawes wrote:
"An object that can be written to, or read from, or both. A file has certain attributes, including access permissions and type. File types include regular file, character special file, block special file, FIFO special file, symbolic link, socket, and directory. Other types of files may be supported by the implementation."
Why do we follow specific definition of file in a portable library? Can we start with the most simple names -- 'parent' and 'name'? What's wrong with them, and what kind of confusion they will cause?
It is a question of more explicit versus less explicit.
Ok, I'll vote for parent + name, then.
The term "filename extension" is well established. See http://en.wikipedia.org/wiki/Filename_extension or google for "file extension".
Oh, using wikipedia and number of google hits to establish naming sounds interesting -- you can some up with random API. Note that "file extension" has 12'000'000 hits, whereas "file suffix" has 2'000'000 hits, which does not seem to be on overwhelming difference. Also, I don't know how to get google to produce hits only relevant to names of API function in some libraries.
www.google.com/codesearch and the other code search sites are useful in determining the relative popularity of names, but that's only one aspect of choosing good names, much less designing an API.
Heh -- it was *you* who tried to use Google/Wikipedia as an argument in naming discussion. - Volodya