David Abrahams wrote:
Beman Dawes wrote:
David Abrahams wrote:
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 :-) Ah! Understood.
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(). Let's say branch_path() is changed to parent_path(). That suggests a full set of names based on the parent/child decomposition of a path:
* Change branch() to parent_path() * Change leaf() to child() * Change basename() to child_prefix() * Change extension() to child_extension()
At first glance, those names seem reasonable clear and self-consistent.
What's your take on that set?
Well, "parent" describes a relationship between the path being operated on and the result. "Child," on the other hand, does not. So that doesn't work for me. I would prefer "parent" and "filename." I would prefer "drop_extension" and "extension," although I rather liked Volodya's "stem" suggestion.
I like "stem" too. Trying to put that all together: * Change branch() to parent_path() * Change leaf() to file_name() * Change basename() to stem() * extension() remains extension() The models are: * A path is composed of a parent path and file name. * A file name is composed of a stem and an extension. I do intend to change make stem() and extension() member functions; I want to preserve the design convention that lexical operations on paths are supplied as member functions while the filesystem operations on paths are free functions. --Beman