Boost logo

Boost :

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
>> 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. 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at