abstract paths

[Mark Thornton]

Alan Snyder wrote:
> I'll try to respond to all the comments at once, since they seem to be 
> related.
>
> What I have in mind when I say abstract path (I'll call it 
> AbstractPath for now, even though the name is already taken) is a type 
> whose attributes are (1) a sequence of Strings, (2) an optional String 
> representing a Root, (3) a boolean indicating whether the path is 
> absolute or relative. There would need to be a way of constructing an 
> AbstractPath from these attributes as separate objects (this is not 
> the same as parsing a single string). There would need to be a method 
> on Path that directly converts a bound Path to an AbstractPath, 
> preserving the interpretation of the Path, such as whether it is 
> absolute or relative (i.e., not necessarily just unparsing and parsing 
> it). There should probably be a method on a FileSystem that takes an 
> AbstractPath and returns a bound Path, again, preserving the original 
> interpretation rather than unparsing and parsing.
>
> I would expect the following code
>
>     Path p1;    // already obtained from somewhere
>     AbstractPath a = p1.toAbstractPath();
>     FileSystem fs = p1.getFileSystem();
>     Path p2 = fs.bind(a);
>
> to result in p1.equals(p2) being true.
>
> I would expect the methods I listed in my previous email to work on 
> AbstractPaths without using any provider-dependent code.
How well does a URI match what you expect of an abstract path? It seems 
to me that you are looking for a universal path form (not to be confused 
with UNC).

Mark Thornton