Re: [boost] [filesystem] "leaf"

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-05-30 08:53:10

Scott McMurray wrote:
> On Thu, May 29, 2008 at 11:33 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
>> Beman Dawes wrote:
>>> ...An
>>> alternative set I'd be comfortable with would be tail() for the current
>>> leaf() and head_path() for the current branch_path().
>> Hum... After sending that, I read Johan RÃ¥de's "parent" suggestion.
>>
>> I really like parent_path() for the current branch_path().
>>
> 
> I do too.
> 
>> That leaves leaf(). tail() is arguably slightly better, but not by a
>> lot. Other possibilities:
>>
> 
> I really dislike tail() for this purpose, since as far as I'm
> concerned, tail is a list term that returns a list (or the empty
> list), so having a tail function that returns a single element is even
> less intuitive than leaf.
> 
> The name I usually see for that is last, which isn't all that good,
> with init for the parent directory part.  Using snoc for operator/ is
> definitely not a good plan.
> 
> How about p == p.parent_path() / p.current_name()?

That's a nice way to describe the relationships. Thanks!

"current_name" doesn't convey the right connotation to me.

What about p == p.parent_path() / p.last_name() ?

That seems pretty good to me.

> And while we're on the subject of decomposition, would it be
> worthwhile to add decomposition from the front in terms of an
> uncomplete() function that'd give a relative path from one full path
> to another?  uncomplete(/foo/new, /foo/bar) => ../new
> 
> I think that complete is the only function without a corresponding inverse.

Do you have a compelling use case beyond complete not having an inverse?

Thanks for the suggestions,

--Beman