Re: [boost] [filesystem] "leaf"

From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-05-30 09:38:02

On Fri, May 30, 2008 at 8:53 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
> Scott McMurray wrote:
>>
>> 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.
>

Current does seem stateful or time-dependant, so I agree that it's weak.

I'm happy enough with last_name, though it does make me think of
first_name and middle_initial ;)

Though since containers use back(), not last(), perhaps it should be
back_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.
>
> Do you have a compelling use case beyond complete not having an inverse?
>

Any time you get a full path (from, say, an open file dialog) and
you'd rather have the relative one to save, so that it won't break
when moved around.  An IDE, for example, would prefer a path relative
to the project file's directory, so that you could check it out of SVN
to whatever folder.

~ Scott