Re: [boost] [filesystem] Function name changes

From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-07-03 15:33:11

On Thu, Jul 3, 2008 at 13:36, David Abrahams <dave_at_[hidden]> wrote:
>
> 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.
>  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()?
>

As yet another option, how about super_path? Similar to parent_path,
but without the ./.. connotation that was the complaint.

I have to say I still don't find base_name intuitive, precedent or
not.  Maybe this_name, thinking of super/this/sub?

>> * Change basename() to base_name_prefix().
>> * Change to extension() to base_name_extension().
>>
>> This change is to avoid confusion with base_name().

extension was nice and clear, so p.this_name() ==
extensionless_name(p) + extension(p) could be a different way of
approaching this.

But neither the original or the proposed new names for these bother me.

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

Hopefully the fact that basename was namespace-scope while the
proposed base_name is a member will help prevent that.

Thanks for continuing this,
~ Scott