Re: [platform-core-dev] Pathology, take two

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Your suggestion actually looks very
similar to what I was thinking. I differ on only two of your points below:

2) This is a perfectly reasonable change
for this two-arg constructor.  However, I don't think it turns out
to be very helpful. As I said in a previous comment, this passes the buck
to the plugin writer to parse the device themselves and call the constructor
appropriately. I.e., it requires platform-specific behaviour on the part
of the caller.  Since the fromOSString factory method is designed
to take this pain away, I don't see much reason for leaving the two-arg
constructor there at all.

3) It's fine to say they are two separate
fields, but as a practical matter we still need to be able to store these
paths in text-based property files. I.e., there needs to be a delimiter
between the two separate components.  This is what the first cut of
my proposal was trying to achieve with the '//' delimiter between device
and segments.  This is a nice solution, but is not backwards compatible
with data files written by earlier versions of Eclipse. This in itself
is not an insurmountable hurdle, since data file versions can be changed
and migration code can be written. However, this imposes significant pain
on plugin writers to write that migration code, and decreases the chance
of the proposal being accepted by the wider community for whom backward
compatibility is very important.

John.

Ed Warnicke <eaw@xxxxxxxxx>
Sent by: platform-core-dev-admin@xxxxxxxxxxx

10/06/2004 04:38 AM

Please respond to
platform-core-dev

To	platform-core-dev@xxxxxxxxxxx
cc	eclipse-external@xxxxxxxxxxxxxxxxxx
Subject	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.