From: David Abrahams (dave_at_[hidden])
Date: 2008-05-21 02:27:08
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
>> 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.
-- 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