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