Re: [boost] [filesystem] Function name changes

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
http://www.boostpro.com