abstract paths

[Mark Thornton]

Alan Snyder wrote:
> Thanks to the article by Elliotte Harold, I have become aware of this 
> work. I want to say that it is long overdue and will be much appreciated.
>
> I want to make a pitch for supporting fully abstract paths, that is, 
> paths that are not bound to any file system or file system 
> implementation. A fully abstract path is simply a sequence of names. 
> Before it can be used to access a resource, it must be presented to a 
> file system (which might convert it to a bound path as in the current 
> design).
>
> Fully abstract paths can be useful whenever you are performing cross 
> file system operations, such as mirroring. The same relative fully 
> abstract path can be presented to two file systems to access resources 
> that correspond by name. Fully abstract paths could also be used in a 
> catalog (as might be created by a backup program), which stores 
> metadata but does not contain the actual files.
>
> I would imagine that fully abstract paths could be supported in the 
> current design fairly easily by defining a concrete superclass of Path.
>
>   Alan
>
I think only relative 'abstract' paths make much sense and these could 
be represented as List<String>. So possibly add Path.get(List<String>) 
and FileSystem.getPath(List<String>) methods.

Mark Thornton