Proposal for std.path replacement

[Jim]

Lars T. Kyllingstad Wrote:

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


Not quite sure it would be that easy.
http://en.wikipedia.org/wiki/URI_scheme