Re: [boost] [Boost-users] [Filesystem V3] Filesystem Version 3 beta 1 available for download and comment

Subject: Re: [boost] [Boost-users] [Filesystem V3] Filesystem Version 3 beta 1 available for download and comment
From: Beman Dawes (bdawes_at_[hidden])
Date: 2010-02-21 11:39:18

On Thu, Feb 18, 2010 at 11:43 PM, Scott McMurray
<me22.ca+boost_at_[hidden]> wrote:
> On 18 February 2010 09:43, Beman Dawes <bdawes_at_[hidden]> wrote:
>> The first beta release of Boost.Filesystem Version 3 is now available.
>>
>
> Great!  I've been looking forward to it.
>
> A few comments:
>
> - read_symlink
>
> Thank you!

Like a lot of features, it came about because someone asked for it.

> - path::preferred
>
> The implications of this one are strange to me.  I would have expected
> the path itself to always be stored in the portable grammar,

It is more efficient to store the pathname in the native format. A
pathname is created only once, but it may be used many times. There
may be some system specific aspects of the naive format that can't be
represented in the generic format.

> with the
> user-oriented display only done as a display issue, by using
> path::native.
>
> - path::absolute
>
> I agree that a verb here is important, since it's a mutator.  I don't
> have anything cleverer than make_absolute, though.

make_absolute() seems clearer than absolute(), so I'll go with that
unless someone comes up with something even better.

>  It's a shame that
> make_relative can't be done portably for anything beyond different
> root_names.

Yep. I tried briefly to come up with a make_relative spec, but didn't
have any brainstorms. I'd like to be sure that there are reasonably
compelling real world use cases before adding yet another function.

>
> - canonical(p)
>
> I'd like a non-member function specified to take an absolute path,
> expand any symlinks, and collapse any ".." path elements.
>
> Whether it should allow a context to work with relative paths I'm unsure.
>

Essentially a "tell me what this path resolves to" function? I've
occasionally though about such a function, but it always ended up be
lower priority than other work.

> - regarding complete
>
> It seems like it'd just be canonical(path(a).absolute(b)), so it might
> not be needed.

I was also thinking that the need may have evaporated as other
functionality was added.

>  I suppose in some ways it's the version of canonical
> that takes a context.

Yes.

> - uncomplete(p, base)
>
> My pet request.  It may be useful to simplify other functions as well,
> since there's no current way to go from an absolute path to a relative
> one, meaning that most functions need to handle relative ones even
> when that might not be natural.  With this functionality,
> preconditions requiring absolute paths would be less onerous.
>
>    Precondition: p.is_absolute() && base.is_absolute()
>
>    Effects: Extracts a path, rp, from p relative to base such that
> canonical(p) == complete(rp, base).  Any ".." path elements in rp form
> a prefix.
>
>    Returns: The extracted path.
>
>    Postconditions: For the returned path, rp, rp.is_relative() ==
> (p.root_name() == b.root_name()).
>
> [Notes: This function simplifies paths by omitting context.  It is
> particularly useful for serializing paths such that it can be usefully
> moved between hosts where the context may be different, such as inside
> source control trees.  It can also be helpful for display to users,
> such as in shells where paths are often shown relative to $HOME.
>
> In the presence of symlinks, the result of this function may differ
> between implementations, as some may expand symlinks that others may
> not.  The simplest implementation uses canonical to expand both p and
> base, then removes the common prefix and prepends the requisite ".."
> elements.  Smarter implementations will avoid expanding symlinks
> unnecessarily.  No implementation is expected to discover new symlinks
> to return paths with fewer elements.]

Interesting. I'm considering this a "Wish list feature request", so
don't plan to do anything about it for the initial V3 release.

Right now, all my effort is focused on issues that need to be fixed
before the initial V3 release. Once that is in a good enough state to
go into trunk (and release branch once tests are stable), I'll think
about feature requests.

Thanks,

--Beman