Path as an object in std.path

[Michel Fortin]

On 2013-06-06 15:36:15 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> 8. There really isn't any such thing as a portable path representation. 
> It's more than just \ vs /. There are the drive prefixes in Windows 
> that have no analog in Linux. Sometimes case matters in Linux, where it 
> would be ignored under Windows. There are 8.3 issues sometimes. The 
> only thing you can do is come up with a subset of what works across 
> systems, and then of course you have to go back to using strings when 
> you need to access D:\foo\abc.c

Actually, there is one portable representation for paths: URLs. More 
specifically "file:" URLs if we're limiting ourselves to filesystem 
paths. Relative URLs should probably count too.

But otherwise, that's all true. To correctly normalize a path, you need 
to know which underlying filesystem is in use. Today's operating 
systems can mix and match case-sensitive, case-preserving, and 
case-insensitive filesystems, different restrictions on file names, and 
sometime have obscure restrictions/normalization when using old APIs on 
newer filesystenm. You can't really normalize a path without making a 
lot of assumptions.

Of course, that's not an argument for or against having a path object 
to encapsulate the differences. But I'd tend to say that what the path 
object can do is more limited than one might think at first glance.

As a side note, Apple is currently asking application developers to use 
URLs instead of raw paths to local files. Using URLs makes it possible 
for instance to attach "bookmarks" keys on path (in the query string) 
that can more or less automatically punch a hole in the sandbox when 
accessing a file (which can expire or be revoked). Pretty much all 
recent Cocoa APIs take url objects instead of path strings.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/