On Wed, Mar 30, 2016 at 6:42 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Chris Angelico writes:
On Wed, Mar 30, 2016 at 3:06 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
This means that URIs can be canonicalized syntactically, while doing so with file system paths is risky.
Or there are two operations: canonicalizing by components, and rendering a "true path", which requires file system access (stat every component).
That's not to my taste because while you do need to make that choice for filesystem paths, it's always safe (in the sense of "you're buggy, not me!") to canonicalize a URI.
Yes, this is true; for a non-file-system URI, the "true path" would simply be identical to the component-based canonicalization.
Also, RFC 3896 explicitly refuses to require URIs to make any physical sense, while it's an error for a filesystem path to refer to a non-existent object. In other words, URIs are abstract syntax to which you can assign whatever semantics you want (as long as they are compatible with the syntax), while filesystem paths are actual paths in a graph that is instantiated in hardware storage.
Hmm. Not sure what you mean by that error - how else could you create a new file, than by identifying a path that does not exist? You're absolutely right that URIs have no specific physical meaning, yet they do have definite semantic meaning; an HTTP client can (and should) resolve relative URLs itself, rather than simply sticking "../../static/main.css" on the end of the current URL.
I suspect you won't have a problem with that distinction, but ISTM that it's the exact opposite of the way the "let's derive Path from str" (or from "BaseString" or whatever) crowd want to think (filesystem paths are a subset of strings).
Even if a file system path is a special form of string, this will work. It's just that the semantics would have to be defined sans canonicalization, with two methods that do that. But I am liking the line of thinking (not posted in this exact thread, so I'm not sure who said it - sorry!) that Paths are as abstract as integers and text strings, and that they should have no particular tie to their mechanical implementation. The string "/home/rosuav/foo.py" should be more like a "path display" (by analogy with lists etc) than an actual Path. ChrisA