Re: [boost] [filesystem] "leaf"

From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-05-29 12:22:39

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

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.

(The name could obviously be improved.  incomplete sounds like a
property, so I don't like it.  it'd be nice to use relative, but that
conflicts conceptually with .relative_path().  Perhaps relative_path
could use a different name too?  I usually thing of a relative path as
relative to some folder, not to the root, even on windows.  local_path
is ok, if not great. p == p.root_path() / p.local_path() is
reasonable.)