On 2013-06-06 15:36:15 +0000, Walter Bright <newshou...@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.for...@michelf.ca http://michelf.ca/
