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
> 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
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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk