Re: [boost] [Filesystem] Proposal: make filesystem generic-programming friendly

Subject: Re: [boost] [Filesystem] Proposal: make filesystem generic-programming friendly
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2014-01-11 12:37:43

I replied yesterday but it looks like Gnus ate it.  

Klaim - Joël Lamotte <mjklaim <at> gmail.com> writes:

> My use case is to be able to easily choose between real file system and
> archive file system at runtime.
> To implement archie file work I currently use PhysFS [1].
> 
> However I have several totally different projects with this need of runtime
> choice of filesystem and currently
> I have to add project-domain-specific file manipulation layers to each
> project which
> is therefore implemented twice, once with boost::filesystem and the other
> with PhysFS.
> That's a lot of time spent on making sure they do the same things and it is
> easily error prone.
> A solution to help me write my project-specific algorithms once would be
> very helpful.

If we were to go ahead with my proposal, you could write a thin layer on top
of PhysFS to make it a model of FilesystemConcept.  Boost.Filesystem would
also model this concept, and then write your algorithms once for both of them.

> Also, it seems that it would the solve the same problems for
> std::filesystem? It was a concern I had recently when thinking about it.

The impeding standard was what caused me to release the draft now.  I'd like
to get this into Boost.Filesystem before the standard (which is based on it)
is frozen.

> Question: it is not totally clear to me what the proposal wants to do with
> the boost::filesystem::path class exactly.

True, I did gloss over this a bit.

> The example suggests that boost::filesystem::path would be usable for any
> filesystem implementation.

Perhaps I overstated that.  What I was trying to say was that it should be
possible to use the same path class for multiple filesystems.  That may mean
reusing boost::filesystem::path, if its behaviour makes sense for that
filesystem, or something else.  The only case I can think of where *every*
boost::filesystem::path method is applicable, would be when mocking the
local filesystem.

Even a filesystem implementation that connects to a remote filesystem using
it's native path format, would not be able to use boost::filesystem::path
because platform-specific methods would render the answer based on the
*local* platform, rather than the remote one.  A path class for such a
filesystem would be almost identical to boost::filesystem::path, except for
basing its platform-specific decisions on the remote platform.

> In which case, do you suggest to remove absolute() and cannonical() from
> boost::filesystem::path so that it would only be possible to get these
> versions
>  using one of the namespace functions overload of the same name, one for
> local_filesystem(), the other taking a filesystem as parametter?

absolute() and canonical() are already free functions, so these would just
be overloaded or turned into filesystem object methods (whichever API design
we choose) just like the other operations.

But you probably mean make_absolute().  As far as I can see, this is the
only filesystem-instance-specific method in boost::filesystem::path and
would, ideally, not be there at all.  However, in practice, it does no harm
because it won't be in FilesystemPathConcept, so generic code cannot rely on it.

Models of FilesystemPathConcept are permitted to have
local-platform-specific behaviour for certain methods.  For example,
native() is allowed to vary the appearance of the path it returns based on
local operating-system conventions.  For example, a ZIP-file filesystem
should be allowed to format paths using backslashes on Windows.

However, filesystem-instance-specific behaviour should not be permitted as
(apart from the local filesystem), that requires access to a filesystem
object instance.

Glad to hear any further thoughts. 

Alex