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 15:55:37

On Sat, Mar 23, 2013 at 12:36 PM, Yakov Galka <ybungalobill_at_[hidden]>wrote:

> On Sat, Mar 23, 2013 at 2:42 PM, Joseph Van Riper <
> fleeb.fantastique_at_[hidden]> wrote:
>
> > [...]

> >  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).
> >
> What are the separator characters in c:\x.txt, c:x.txt, or
> SYS$SYSDEVICE:[USER.DOCS]PHOTO.JPG:8?
>

* C:\x.txt: : for root, \ for branches (and branches between leaves).
* C:x.txt: : for root, leading right into a leaf that would be wherever
your sense of 'current directory' should be.  If someone entered this,
you'd want to expand this to something like C:\my\current\folder\x.txt
before working with it, unless you want a sense of 'current folder'.  But
that raises an interesting point I hadn't really considered... paths
identified by a name, like Windows' %WINDOW% folder, etc.  I don't know how
often other operating systems use specialized folders that identify to a
particular name, but Windows has several folder locations that one might
identify with a particular name, even beyond expanding an environment
variable (e.g. the Program Files folder).  Yeah, this case requires some
thought.
* SYS$SYSDEVICE:[USER.DOCS]PHOTO.JPG:8: : for root, . for folders, with []
characters surrounding the branches, showing the leaves.  In VMS, the leaf
has an added attribute (I never discussed the attributes of a leaf) of a
revision in addition to an extension, which makes that file system a tad
more unique.  Good ol' VMS.

At the end of the day, in at least two of the three cases, the
representation of the path is unique to the system they're on, and could be
treated with functions specific to those representations.  I'm suggesting,
I suppose, a separation between its string representation for a path, and
how the path is organized in memory.  This could make it possible to create
a VMS-style string representation of a Windows file system path, as silly
as that might seem.

> I claim that the "paths are strings" mindset is too simplistic, narrow
> minded and useless for defining path arithmetic. It is still true that we
> *do* want to represent paths as strings, and actually a library that would
> work with std::strings has its own right for existence. However, any paths
> library shall not have the word "separator" in its documentation for
> anything other than the platform specific parts.
>

I agree with this.  The underlying representation should be more
sophisticated.  But we still need a representation for a particular path as
a string, or such a library isn't very useful for most cases.

Manipulate a path as if it were something other than a string, and when
you've finished manipulating it, call a function to expand it into a string
(perhaps for use in an API that depends upon such a string, or for storage,
or whatever).

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.
>
> Not really, the syntax is different.
>

I'm not sure I see what you mean here.  Perhaps I didn't express my
thoughts well.  That wouldn't be a surprise, since I was writing with
brevity in mind and not clarity.

I'm observing that the operating system provides an API that allow you to
traverse a file system in a manner like working with a tree (or forest if
you prefer).  Similarly, the Windows operating system provides an API that
allows you to traverse the registry in a manner like working with a tree.
 You can go to a parent, you have base nodes, and you have branches and
leaves (just with different names... a file in the file system is analogous
to a registry item in the registry).  I'm observing that several systems
seem to use this paradigm, and there's a utility in abstracting it.

Interestingly, you can represent a particular path in a file system using a
string, and you can represent a particular path in the Windows registry
using a string.  Note that I mean the path to the item, and not the item
itself... obviously you'd need more than a string to represent a particular
file within the file system, heh.  I think for many use cases where the
aforementioned paradigm is used, a string representation for a specific
node within the system also exists.

If you build individual libraries that map a file system's API to a
library's API (a bridge between the two, if you will), you could build a
library with eligible library backends that abstract the system API calls
to make them common.  And you could build a library that takes the
underlying tree-like path object and represent it as a string in some
format.

So, let's say we had a library with a kind of generic path object with a
function 'branches()'.  That function could return a set of paths that
represent other branches found within that particular path object (if
any... yes, it should be possible for the path you have to not exist, in
which case perhaps it could be created, but you can't find branches or
leaves).  So, if the path represented a file system path, you'd see other
folders.  If it represented a key in the Windows registry, it would show
other keys.

Now, if you wanted to take a particular path object and represent it as a
string, you might call a function that takes the path as an argument, and
it spits out a string representation of that path that is unique to how
that function builds strings from paths.  So, it could represent the path
with the posix-style forward-slash separator, or the VMS-style
root:[folder]file format, or even something else like a
root:folder.folder.file format.

Since the function that builds strings is simply calling an established set
of functions within the generic 'path' like object, it can do this
regardless of whether the path represents a Windows file system, windows
registry, VMS file system, or an SNMP OID.  This is what I wanted to
suggest.

- Trey