Proposal for std.path replacement

[Lars T. Kyllingstad]

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