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