From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2008-07-03 20:52:56
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