Re: [boost] [filesystem] "leaf"

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
>>> to.
>> 
>> 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:
http://lists.boost.org/Archives/boost/2003/08/50910.php

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

  path members:

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

    std::string root_name( ): OK, but maybe should be called "root" and
        return boost::optional<path>

    std::string leaf( ): should be basename().  back(), tail() and
                          p.split()[1].string() are viable alternatives

    std::string branch_path( ): should be dirname()

    bool empty( ): OK, although this seems like a really uninteresting
        question to ask.

    iterator: OK

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

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com