[
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