"Lars T. Kyllingstad" <public@kyllingen.NOSPAMnet> wrote in message news:il28cm$2phc$1...@digitalmars.com... > On Sun, 06 Mar 2011 16:49:59 -0500, Nick Sabalausky wrote: > >> "Lars T. Kyllingstad" <public@kyllingen.NOSPAMnet> wrote in message >> news:il09fp$2h5d$1...@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.