|
Boost : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-07-04 09:25:35
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk