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

Subject: Re: [boost] [Filesystem] v3 path separator changes
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2013-03-23 16:42:26

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

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

[...]
> > 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.

Whatever definition you give here, it won't let you parse the path with a
simple split() or concatenate it with a simple join(). Therefore all such
definition would be useless, and thus I see no point in talking about
"separators" in a portable path library.

>  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 in order to do this you must have a 'current director', which means
that you must query the filesystem. A path may point to a device that does
not yet exist, like a drive that will be mounted later. The expansion must
be done later, when you intend to *resolve* the path.

>  But
> that raises an interesting point I hadn't really considered... paths
> identified by a name, like Windows' %WINDOW% folder, etc. [...]
>
These are environment variables and I don't think mixing them with a
filesystem library is a good idea. This would mix unrelated concepts.

[...]
> > 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.

I haven't said this. The underlining representation may or may not be a
string. What I say is that the interface shall not be defined syntactically.

> 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). [...]
>
Exactly.

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). [...]  This is what I wanted to
> suggest.
>
I agree in general. What you describe is very similar to [Poco::Path](
http://pocoproject.org/slides/080-Files.pdf), which seems to get right many
things boost didn't.

-- 
Yakov