abstract paths

[Alan Snyder]

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.

I would expect that the methods on AbstractPaths would mirror the  
equivalent methods on the bound Paths. (If I remember my college math,  
the mapping is a homeomorphism. :-) ) There may be cases where an  
operation that the bound Path can do (such as resolve using a relative  
path having a root) is either rejected by AbstractPath or does  
something different. I don't see that as a problem, but I'm not sure I  
understand enough about possible provider dependent behaviors.

I would expect AbstractPaths to interoperate with bound Paths wherever  
that makes sense. In particular, it should work in the simple cases,  
such as passing a relative, rootless AbstractPath as a parameter to  
resolve() on a bound Path. (In current cases of interoperation between  
Paths from different providers, an AbstractPath would be the ideal  
intermediate form, would it not?)

One place where I would use AbstractPaths is in situations where I  
want to make sure my code does not access the actual file system. For  
a file catalog, I might create a subclass of (my) AbstractPath that  
can return file metadata (from the catalog). The file catalog program  
needs to serialize AbstractPaths when writing the catalog, but when it  
runs, it should not need to be doing any parsing of paths.

Hopefully, it is now obvious that "/foo" is not an AbstractPath, it is  
a string. When an AbstractPath is created, the absolute/relative  
attribute must be specified.

(It sounds like the "My Documents" example would be best handled using  
a symbolic root. In other words, the Windows provider might support a  
root of "${MY_DOCUMENTS}" just as the Unix provider might support a  
root of "${HOME}". Just a thought, and a separate topic, I believe.)


On Jul 18, 2008, at 1:30 AM, Alan Bateman wrote:

>
> 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?).
>
>> 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.