[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-core-dev] Pathology, take two
|
On your response:
2) If a plugin author has also been convoluting two fields into one
string, then they will have to handle unconvoluting
them. Can you point to a case where this is so? I don't think it's
too much to ask for a real solution to the problem.
3) First, we can store the Path in a text based properties file as a two
field data structure. If today you had
org.eclipse.stored_path_here
then you would use
org.eclipse.stored_path_here.path
org.eclipse.stored_path_here.device
Second, I am still waiting for a response on how to handle the user
impacting display issues I raised. I suspect that
handling all of the user related display issues correctly will turn
out to be, in the end, far more painful than
migration code for breaking persistent properties into two fields
from one. To handle the persistent properties
issue consider providing the following two additional static methods
DeprecatedPath.pathFromOldString(String) - to make a call to
Path(String device, String path) after
breaking the device off at leading colons. So
DeprecatedPath.pathFromOldString("foo:bar") would call
Path("foo","bar")
DeprecatedPath.getPathFromResourceBundle(String) - which given a
name like
"org.eclipse.stored_path_here" would look first for
"org.eclipse.stored_path_here.path" and
"org.eclipse.stored_path_here.device". If the ".path" and ".device"
where found it would call
Path(String,String) with those values. Otherwise it would proceed
to look for
"org.eclipse.stored_path_here" and pass it's value to
DeprecatedPath.pathFromOldString(String).
This should reduce some of the pain of migrating persistent stores
(at least those stored as properties
files).
In general, we only get to fix this once, we might as well really fix
the actual root problem.
Ed
John Arthorne wrote:
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.