From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-07-05 07:18:47
Vladimir Prus wrote:
> 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?
It is a question of more explicit versus less explicit.
>> The term "filename extension" is well established. See
>> http://en.wikipedia.org/wiki/Filename_extension or google for "file
> 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.