Boost logo

Boost :

From: Scott McMurray ([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

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