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