Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-03 16:16:29

Beman Dawes wrote:
> David Abrahams wrote:
>> Beman Dawes wrote:
>>> * Change leaf() to base_name().
>>> * Change branch() to base_path().
>> What does the latter do, again? Oh, yeah, it returns the path to the
>> directory containing the file indicated by the path object.
>> I'm sorry, but I don't like base_path() much. We know it is going to
>> return a path, so the "path" part of the name doesn't tell me much about
>> what this function does. The only thing left to go on is the meaning of
>> "base."
>> Well I'm afraid we don't know what that is. The (only) good reason to
>> use base_name() is that there is precedent; it's not because it makes
>> particularly "good sense." You yourself find it counterintuitive, IIUC.
> That's correct. I'm only suggesting it because of the precedent.
>> If "base" _did_ make any sense, I would guess that base_path() was the
>> identity function.
>> How about parent_directory(), containing_directory(), container_path(),
>> container(), or parent()?
> The objection raised in the discussion to the names with "parent" is
> that the resulting path is only the parent path in the absence of
> symbolic links. Same objection would apply to your other suggestions.]

I find that objection specious.

> Maybe that isn't all that strong an argument; parent_path() is quite
> clear to me and fits into the overall naming scheme. The impact of
> symlinks may just be a quirk we can live with.
> parent_directory() or parent() always look to me like they refer to one
> level up only.

I think parent_path or parent can actually be viewed as completely being
correct in the presence of symlinks. A path is a path, not a file or
directory (or symlink). There may or may not be a file or directory
there. So the parent of a path is also a path, regardless of the
underlying filesystem structure.

>>> Comments?
>> I worry a bit about the chance of silent misbehavior due to
>> basename/base_name spelling errors, and about what happens when both
>> names make it into the same codebase.
> I don't like that either, but (1) there doesn't seem much choice if
> "base*" is to be the new name, and (2) the problem doesn't last
> indefinitely since the deprecated form of the names would go away in say
> one year.

FWIW, though I think it's probably a good idea to use base_name as you
are suggesting, I was much less attached to the idea of using it to mean
what is currently called leaf() than I was opposed to the idea of using
it to mean something else, if you catch my drift :-)

So one other option that avoids the above issues (not that I'm pushing
this route) is to pick another name for what you currently call leaf().

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at