Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-core-dev] Pathology, take two
I've been thinking a bit more about this, particularly in light of your proposals. One of 
the comments you made in your API section jumped out at me:
"Path constructors (Path(String) and Path(String,String)). These constructors are the root of the existing problems, since they are designed to accept both platform-specific paths, and platform-neutral paths produced by a previous call to IPath.toString. "
I would maintain that the constructors are not the root of the problem 'since they are designed to accept both platform-specific paths, and platform-neutral paths' but rather because they are designed to try to accept a convolution of two pieces of information, a device, and a path. All of the roots of the issue come back to this. By trying to encode your device *in* your path you create a gordian 
problem.
The real root of the problem seems to be trying to represent a two field data structure with 
a single argument constructor.  Unsurprisingly, it is problematic.

Consider the following possible solution:
1) Deprecate Path(String), Path's are two data field objects and should always be created that way. 2) Path(String device ,String path) interprets device as the device, and makes 
   no attempt to interpret a device into the contents of path.
3) Serialize Path as a structure containing two fields (as it properly is), not one. 4) Provide a Path.fromOString(String) factory method to 'do the right thing' by platform when handed a string (presumable user provided). For example on windows Path.fromOString("C:\\foo") would call Path("C:","/foo"), while on a posix system it would call Path("C:\\foo") (resulting 
   in a file named C:\foo).
5) Use Path.fromOSString(String) in places where the user might provide single string input (to handle the 
   Window drive letter issue).
6) Path.getPath() and Path.getDevice() could provide the string representations of the path and 
   device fields respectively.
7) Path.toOSString() could still provide the platform specific representation for passing to java.io.File. 
8)   Deprecate isValidPath and isValidSegment.

Thoughts?

Ed

John Arthorne wrote:
I have updated the valid path characters proposal with a new solution. Essentially, where the previous proposal for toString/fromString escaped the device separator with a double slash (c:\foo encoded as c:\\\foo), the new solution leaves the device separator alone, and instead escapes literal colon characters in path segments (/foo:bar encoded as /foo::bar). This preserves the important property of full backward compatibility with the Eclipse 3.0 implementation of IPath.toString, removing the need for clients who currently serialize paths from having to migrate their data. Read the revised proposal for all the details. Comments welcome.
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/path_changes.html

Back to the top