[phobos] next release (meaning of path)

[Jonathan M Davis]

On Monday 03 January 2011 04:42:49 Steve Schveighoffer wrote:
> Would it be enough to have a function that takes a string (or inout(char)[]
> if possible) and returns a string[] with the path elements?  Also, a
> function to do the reverse.
> 
> I agree we need something to abstract as much as possible the path elements
> (separator, drive, extension, etc.), but the huge benefit of using a string
> for a path is that when a path struct exists, it's often used as the
> parameter type for paths.  This results in one having to wrap their paths
> in a Path struct just to call some function, even though they don't care
> about manipulating it.  I remember when using Tango, there were types to
> deal with all sorts of things (like files and paths) and I always had to
> use the docs when using them.  It was not very intuitive.

One of the major reasons that some folks want a Path struct is so that function 
_don't_ take strings for paths. That way, paths are their own type, and you can 
overload on them and the like. Personally, I think that they have a point, but 
I'm not sure that I care all that much. However, if all it takes to have Path 
struct from a string is Path("my/path/string"), then it's quite straightforward 
to get a Path struct from a string. Getting a string out of it could then be as 
simple as toString(), though if you do anything anywhere near as fancy as 
Boost's path type ( http://is.gd/k0Q3Q ),then you could have it do things like 
giving you the absolute version of the path, or the canonicalized version, or 
other similar versions of it, giving you quite a bit more flexibility. Boost's 
path stuff is fairly fancy in what it does for you, and encapsulating all of that 
in a class or struct has its benefits. I would be worried about it being overkill 
though. If we do go down that path, I don't think that we're going to want 
something quite as complicated as what Boost has.

Having a function for moving between string and string[] could definitely be 
useful, but pretty quickly you get into the problem over whether functions 
should be taking string or string[]. With a separate path type, it's clear. And 
if it's a separate type, then you could treat it as one entity or as its pieces 
without having to convert it, since it would all be encapsulated.

Also, without a path type, abstracting away stuff is definitely going to be 
harder. As it is, I'm willing to bet that there are plenty of programmers who 
will just use / or \ rather then sep. If you wanted to be purist about it (which 
isn't very pragmatic and therefore not very D-like), you'd _never_ write paths 
like "a/b/c" because the separator is hard-coded. Instead, you always do 
something like Path("a", "b", "c") and never care about the separator. In such 
cases, you ideally wouldn't even have to convert it to a string later, because 
all of the file functions would take the Path type. But, as I said, that's likely 
too much of a purist approach for a pragmatic language like D. Certainly, anyone 
who would want to just use strings for paths would get very annoyed with it very 
quickly. But at least you'd never have separator problems.

Another approach which D could take would simply be to treat file names like URIs 
and always use / for the separator. Then any time an OS function is called, the 
path gets converted to whatever the OS uses. If you're going that far, you can 
ever have it convert file names to file names which are legal for the current OS 
or file system so that the programmer doesn't have to worry about which 
characters are legal and which aren't. That would work better with a separate 
path type, but it could work with just strings.

I see definite benefit in having an actual Path type which abstracts various file 
system stuff away, but I also see definite benefit in just using strings. So, I 
don't know which way I'd like std.path to go. If you're doing fancier stuff with 
paths or if you're really trying to make sure that paths are cross-platform, 
then a separate path type would likely be the way to go. But for a lot of stuff, 
simply using strings is good enough. So, I don't know. If std.path continues to 
use strings and doesn't have any kind of separate path type, then I expect that 
someone will create one in a third party library eventually. So, I expect that 
such a path type will be available in D at some point. The question is whether 
such a type should be in Phobos and/or whether it should be the normal way of 
handling paths, or just a nice, alternate way of dealing with paths.

- Jonathan M Davis