Beman Dawes wrote:
Vladimir Prus wrote:
Beman Dawes wrote:
Trying to put that all together:
* Change branch() to parent_path() * Change leaf() to file_name()
Why is "file" there? Path of "a/b/c" can refer to either file, or directory.
A directory is just one particular type of file.
Boost.Filesystem has always followed the POSIX definition of "File":
"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?
Does "file" bring undesired connotation that the path refers to file?
That's what paths do. Refer to files.
* Change basename() to stem() * extension() remains extension()
'stem' is linguistic term, whereas 'extension' is not. To be consistent, it's better to use 'suffix', not 'extension'. Furthermore, I do think we need to pay attention to Qt's suffix vs. completeSuffix distinction -- it seems useful one.
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. - Volodya