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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk