abstract paths

[Alan Bateman]

Alan Snyder wrote:
> 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.
The disconnect may be because it got tied to the discussion as to how to 
convert a path from one file system into a path suitable for a 
completely different file system.

In any case, the suggestion to group the path related methods into an 
interface that Path implements seems to be reasonable suggestion to 
consider. This isn't an easy to do as it might seem. For example, would 
you expect to be able to match or compare abstract paths? Are methods 
such as isAbsolute feasible? (for example "/foo" is an absolute path on 
many file systems but a relative path on Windows). Resolving (or 
joining) paths can't be done without some knowledge of the platform or 
file system. What remains is something that would simply represent a 
sequence of names. That might be okay but perhaps not as useful as you'd 
want. It would be useful if you could outline the of operations you 
would expect do with such a path (would you expect to store them in 
collections for example?).

>
> 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.
Correct, and the reason that methods such as getName don't return a 
String is because this would cause the platform representation to be lost.
>
> 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.
Correct.

> :
> 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 kinda sounds like a type that encapsulates an array of Strings - is 
that right?

-Alan.