[phobos] next release (meaning of path)

[Steve Schveighoffer]

----- Original Message ----
> From: Jonathan M Davis <jmdavisProg at gmx.com>
>
> One of the major reasons that some folks want a Path struct is so that
> function _don't_ take strings for paths.

I understand this, but it's rarely needed.  What would the string represent if 
not a path?  My point was that, the most intuitive interface is to take a 
string.  This looks very intuitive to me:

auto f = openFile("/my/filename");

So likely one would have to support both overloads with one always forwarding to 
the other.  I could be wrong, maybe it's really important to have a path type, 
but my experience with Path types are that they just get in the way most of the 
time.

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

My point is, often you have a path as a string already (an argument to a 
program, or part of a message over the network).  Why should the system do extra 
processing just so it can pass it to another function?

Think of this:

int main(string[] args)
{
   auto f = File(args[1]); // expect args[1] is a valid filename
}

Why would it make sense to require that File receives a valid path type that 
parses the string before handing it over wholesale to the open() syscall?

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

I typically always use / because it mostly works on all OSes.  But in any case, 
I was thinking of a function like this to convert back to a path string:

string toPath(const(char)[][] elements...);

auto pathstr = toPath("a", "b", "c");

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

I don't have a problem with a Path type existing for manipulation (I think you 
need one for URIs), I just am worried about developers saying "oh, there's a 
path type?  Great, that's what I'll use as my path parameter" instead of a 
string.  Then the library gets unnecessarily complex.  Maybe a Path type with a 
disclaimer "do not use as a parameter".

-Steve