Re: [boost] [filesystem] Function name changes

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-04 10:16:06

on Fri Jul 04 2008, Beman Dawes <bdawes-AT-acm.org> wrote:

> 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()

Nit: "parent" is better.  Sticking "path" in the name of a
transformation that returns a path smacks of hungarian notation.

> * 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.

I can't envision any actual issues with it right now, but when you say
"member function" I always wonder if it will limit genericity in some
important way.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com