Proposal for std.path replacement

[Nick Sabalausky]

"Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message 
news:il28cm$2phc$1 at digitalmars.com...
> On Sun, 06 Mar 2011 16:49:59 -0500, Nick Sabalausky wrote:
>
>> "Lars T. Kyllingstad" <public at kyllingen.NOSPAMnet> wrote in message
>> news:il09fp$2h5d$1 at digitalmars.com...
>>> On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote:
>>>>
>>>> What about extending the notion of 'device' (see other post) to cover
>>>> 'http://' and "ftp://"?
>>>> Would it be complicated?
>>>
>>> I don't think std.path should handle general URIs.  It should only have
>>> to deal with the kind of paths you can pass to the functions in
>>> std.file and std.stdio.
>>>
>>>
>> If std.path doesn't handle uri's, then we'd need a whole other set of
>> functions for dealing with uris. And at least a few of the functions
>> would overlap. And then people who want to be able to handle both files
>> and uris will want functions that will seamlessly handle either. So I
>> think it really would be best to just bite the bullet and have std.path
>> handle uri's.
>
> I am now certain that std.path should not give URIs any kind of special
> treatment, for the simple reason that most URIs are also valid paths on
> POSIX.  Specifically, file and directory names may contain the ':'
> character, and multiple consecutive slashes are treated as a single
> slash.  In other words, you can do this:
>
>  mkdir http:
>  mkdir http://www.digitalmars.com
>  cd http://www.digitalmars.com
>
> That means std.path should treat "http:" as just another path component,
> and it should treat "//" on equal footing with "/".  This is how it's
> done now, and it is how it should be.
>

I really wish that wasn't such a good argument. I'm now convinced too, 
albiet reluctantly.

Like anyone else, I certainly beleive that MS has made a number of bad calls 
about certain things. But this is once case where I actually wish unix 
worked the windows way: If unix weren't so permissive about filename chars, 
then we wouldn't have such ambiguities. Oh well. At least URI's have the 
file:/// protocol, so at least you can treat local and remote the same if 
you assume everything to be interpreted as a URI. I just wish it were 
possible to actually *detect* URI vs filepath outside of windows.