On 6/17/10 7:38 PM, Alessio Stalla wrote: […]
Proposed solution: let's invent an ABCL-specific way to print arbitrary pathnames. I proposed #P"abcl:(make-pathname ...)" which is ANSI-compatible and similar enough to what the current code in Pathname.writeToString can produce. Let's use that to print pathnames[1]. Reading them back is as simple as (eval (read-from-string ...)), and no other code needs to be modified.
What do you think?
[1] if not always, at least with dump-form, and when *print-readably* is T and the namestring can't be used. In the latter case currently the #P(...) syntax is used. Btw, probably dump-form *should* bind *print-readably* to T...
Hmmm, not sure I totally like if your proposal is that a PATHNAME is always in the #P"abcl:(make-pathname …)". If you are just proposing this is used when a namestring can't be produced, then I support this (weakly). I would claim that users are pretty cognitively wired at this point to expect a path be a string containing directory separators that we want to obey the "principle of least surprise" here.
Your proposal still doesn't say what ABCL on non-Windows should do with a deserialized PATHNAME that represents a UNC path or has a drive letter in DEVICE.
The current code (as I understand it) on non-Windows would treat a UNC pathname encoded as a string , e.g. "\a\b\c\d", as an error as the '\c' doesn't represent a valid Java char escape sequence, although a case like "\n\n\n\baz" would name the file with char sequence ('' LF LF BS 'a' 'z').
Counter-proposal #1: Note that java.io.File *does* correctly accept "/" as a directory separator under Windows. So, we could potentially just declare "/" as our directory separator in the #P representation on all platforms. I would then make UNC pathnames not have a printable namestring, so inadvertent doubling of path separators doesn't cause confusion. For UNC and drive letters on non-Windows, I would signal a condition when a de-reference was attempted with a restart that tried to DWIM (ignore the UNC share, drop the drive letter reference, or allow a user supplied correction).
Counter-proposal #2: Use URI (IRI?) for the namestring representation. This fits better to the nature of ABCL pathnames i.e. they aren't really just about filesystems at this point. '/' would again be the standard directory path separator. UNCs would get their own scheme (or we would enforce RFC 3986 so that 'file://server/share/dir/file' means UNC whereas 'file:///not/a/server/but/absolute' means an absolute pathname). Drive letters would be part of the URI authority ('file://c:/windows/path'). The same sort of DWIM condition/restarts for Windows-specific semantic on non-Windows would be available. As a user convenience, we might make the 'file://' prefix be optionally inferred.