Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-03 19:47:10


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.

> Although historically basename() and extension() were free functions, my
> sense is the replacements should be basic_path member functions as they
> are closely related to the basic_path decomposition functions. Do you
> have an opinion on that?

I dunno. The extension splitting things feel like they're string
operations more than path operations. It's not clear what should happen
when you ask for the child_prefix of a path with structure, although
drop_extension makes that a little clearer.

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk