Re: [boost] [filesystem] "leaf"

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-05-21 08:20:52

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.

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

--Beman