From: David Abrahams (dave_at_[hidden])
Date: 2008-05-25 01:50:25
on Wed May 21 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
> David Abrahams wrote:
>> on Tue May 20 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
>>> David Abrahams wrote:
>>>> I was just reviewing the filesystem docs and came across "leaf()". I'm
>>>> sure this isn't the first time I've seen it, but this time I picked up a
>>>> little semantic dissonance. Normally we think of "leaf" in the context
>>>> of a tree as being a thing with no children. An interior node like a
>>>> directory that has files or other directories in it is usually not
>>>> called a "leaf."
>>> Right. And "leaf" never returns an interior node of a path.
>> What is an "interior node" of a path? Would you talk about "interior
>> nodes" of a std::vector<string>?
>>>> I wonder if this is the best possible name?
>>> The names used by the filesystem library were carefully chosen as a
>>> matched set. So you can't change a single name without making a
>>> corresponding change to the other names (like "branch") it is related
>> I understand that a change may upset the apple cart, but the fact that
>> the names are interdependent doesn't mean we shouldn't consider
>> different ones.
> Sure. But given that the current names were widely discussed at the time
> of adoption, have been in use for quite a few years, and "basename" is
> already used by the library for a function with different semantics,
> change would be difficult.
Well, I did bring this up almost five years ago:
>>>> Is there a precedent we can draw on in some other language/library? In
>>>> python, it's os.path.basename(p). Perl, php, and the posix basename
>>>> command seem to do something similar.
>>> The filesytem names were chosen to be an improvement over the naming
>>> used by other libraries and/or languages, which always seemed to me to
>>> be misleading. For example, my intuition is that basename("foo.bar")
>>> should yield "foo", not "foo.bar".
>> I don't know why -- basename seems like one of those names that would be
>> semantically void except for the precedent provided by other languages
>> trying to do the same thing. On the face of it, it doesn't suggest
>> anything about the extension part of the name one way or the other. In
>> any case, the 2-argument version of basename does something like what
>> you want in many of those other languages.
>> I'm certainly open to persuasion, but so far, a pathname doesn't seem to
>> resemble a tree in any conceptually useful way, and there seems to be no
>> compelling advantage to inventing our own terminology here.
> If you have a better set of names, why don't you suggest them?
You asked for it. I'm going in the order given by
http://www.ibm.com/developerworks/aix/library/au-boostfs/ because that's
reasonably comprehensive and readable even though it looks like it may
have some serious errors. Don't have time to pore through the full
reference right now.
const std::string& string( ): OK
std::string root_directory( ): OK, but maybe should return
boost::optional<path>. I wonder why we decay to std::string
std::string root_name( ): OK, but maybe should be called "root" and
std::string leaf( ): should be basename(). back(), tail() and
p.split().string() are viable alternatives
std::string branch_path( ): should be dirname()
bool empty( ): OK, although this seems like a really uninteresting
question to ask.
operator/: I've liked that one ever since I came up with it ;-)
The rest of the names look OK to me except for is_regular, which should
be is_file. That name seems overthought and "regular" has all kinds of
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk