David Abrahams wrote:
Bjørn Roald wrote:
Beman Dawes wrote:
* 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?
I am not sure this is any good. Considder the path "../../a/b" and the meaning of parent and child.
The only sensible parent is in the middle and we don't even know it's name. Children are at both ends the implicit "." or "b".
The parent of '../../a/b' is '../../a' The parent of '../../a' is '../..' The parent of '../..' is probably '../../..'
If Beman intended '..' to be the result of the final transformation above, then we should be using something like pop() to describe it.
Doesn't leaf serve 2 functions? If the path points to a directory it returns most derived directory (to make a bad analogy to class hierarchy). If the path points to a file it returns the filename. It seems to me that this duality makes it difficult to choose a meaningful name in the domain of file systems. Personally I think I like parent() - if this is a path to a subdirectory or a file returns a path one level above directory() otherwise returns *this directory() - if this is a path to a file returns a path to the directory that contains the file otherwise returns *this filename() - if this is a path to a file returns a string containing the filename otherwise returns an empty string basename() - if this is a path to a file returns a string containing the filename without its extension otherwise returns an empty string extension() - if this is a path to a file returns a string contains the filename without its basename otherwise returns an empty string Thanks, Michael Marcin