Boost logo

Boost :

From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-07-05 02:38:07


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk