abstract paths

[Alan Snyder]

Well, there does seem to be a disconnect. I am arguing for something  
that would seem to me to be useful (since I have already found a need  
to implement a class of my own just like it), would be easy to do  
(since it is a subset of what is already present), would not break  
anything, but is not essential because it can be done using strings.  
The arguments against seem to be either (1) it is not useful, or (2)  
it is not useful enough, or (3) it is not essential because it can be  
done using strings. I don't think I've heard that it would be hard to  
do or that it would break something.

An abstract path (in my view) is a sequence of names, that may also  
have a root name, and that is either absolute or relative. I did not  
notice this before, but the difference that I now see from Path is  
that Path.getName(index) and Path.getRoot() return Paths rather than  
Strings, although I presume that one can use the toString() method on  
the returned Paths to get these components as strings.

I also assume that the above components are a complete abstract  
description of a Path in its role as a name. In other words, if you  
deconstruct a path into these components and then reconstruct it  
(using the same provider), the result would be an equivalent Path.

If this is wrong, do say so (and put it in the documentation).

In my view, the binding of a Path to a provider does two categories of  
things, which are separable:

(1) Syntactic things, such as defining an external representation for  
a Path, defining components with special interpretations such as "."  
and "..", and perhaps imposing restrictions on the values of components.

(2) Supporting operations that need to access the file system, such as  
operating on the file itself, operating on the file metadata, and  
converting relative Paths to absolute Paths.

My concept of abstract Path imposes no restrictions on the values of  
components, and does not directly support access to any file system.  
It is just a structured name, already parsed so that programs do not  
have to use strings. This is primarily a matter of convenience. I  
suppose one could write a support class that converts a path from one  
FileSystem to another, following your example.

The following Path methods should work on an abstract Path:

compareTo
equals
endsWith
getName(both versions)
getNameCount
getParent
getRoot
isAbsolute
relativize (at least in the simple case)
resolve (at least in the simple case)
startsWith
subpath
toString (using a platform dependent syntax)
iterator (assuming that this method returns the Name components, the  
doc does not say)

One could argue about collapse(), since "." and ".." are not universal.