Re: [boost] [Filesystem] v3 path separator changes

Subject: Re: [boost] [Filesystem] v3 path separator changes
From: Joseph Van Riper (fleeb.fantastique_at_[hidden])
Date: 2013-03-23 08:42:48

On Sat, Mar 23, 2013 at 8:01 AM, Alexander Lamaison <awl03_at_[hidden]>wrote:

> Yakov Galka <ybungalobill_at_[hidden]> writes:
>
> Is it time for a Boost.Filesystem v4 to result from an in-depth
> discussion on here?  I'd hope it would take the best of v3 while
> removing some of the hurt it introduced in the process.
>

Perhaps.  For my needs, v3 is an improvement over v2, which I found just
generally annoying.  All I really needed out of a filesystem library is a
way to work with the filesystem on the native operating system, without
having to constantly look up how to do anything from the documentation.  I
felt version 2 focused overmuch on relatively unusual cases and made it
very annoying for the common case.  Version 3 corrected that, but at some
expense, apparently.  So now that I'm happy, some of the other folks
responding to this thread are not.

I've often wondered about the design of filesystem, to be honest.  It seems
to me as if it could be improved to be more generic, and yield some other
tools that could go beyond being helpful in working with file systems.

> Perhaps people can reply to this thread with any gripes they have?

Well, I wouldn't describe this as a gripe exactly, just an idea for a
different approach, if it tickles anyone's fancy.

I have never seen a file system that wasn't, really, a tree with branches
and leaves.  It can have more than one base, but ultimately, it's a tree.
 As such, it feels to me like a more natural way to work with the file
system is through an object that represents trees, and functions that help
you work with the tree, or represent a particular path on the tree as a
generic string, with a particular separator character (or characters).
 With a sort of understanding that the base is different from a branch,
which is itself different from a leaf.  (E.g.: in the Windows file system,
the base represents drives or network shares, a branch is a folder, and a
leaf is a file).

With that approach, you could also represent the Windows registry using the
same objects (just a different backend to handle the obviously different
API calls).  Or SMNP OIDs.  Or a web site's paths.

You could also do some other things that get rather intriguing, like
serializing a representation of your tree to disk, or comparing pairs of
these trees to find differences.  Which, in a different company, was
something I needed to do, but I confess that it's probably not a common use
for trees... although it's common enough that I saw a paper written on the
subject in the ACM's library.

If boost first had a library that best presented tree representations of
existing objects, then another layer of objects that helped build this tree
or turn it into a string representation for specific paths for different
kinds of needs (windows OS, VMS, web site, etc), it might offer the power
and flexibility that people seem to want out of this library without the
headaches of an API that makes you jump through non-intuitive hoops.

Or does boost already have something like this and I've just been missing
it?

- Trey