On Thu, Jul 3, 2008 at 13:36, David Abrahams <dave@boostpro.com> 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