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 
John,
Does this mean that Path.toOSString() will be used everywhere that a filename is displayed? ie package 
explorer, when viewing a file properties etc?

Ed
John Arthorne wrote:
As I said in another message, the only purpose of toString/fromString is for storing paths in data files. Any interaction with the user would neccessarily be via the OS-specific representation. Two examples of files that store paths are the .project file inside every project, and the .classpath file inside Java projects. There are many more private metadata files with various binary, XML, or property file formats that also store paths. As I said, I'm sure migration is possible in all cases, but identifying and implementing that migration is a substantial effort. I think I have described a real solution to the problem. 



*Ed Warnicke <eaw@xxxxxxxxx>*

10/06/2004 12:02 PM

	
To
	John Arthorne/Ottawa/IBM@IBMCA
cc
	platform-core-dev@xxxxxxxxxxx, eclipse-external@xxxxxxxxxxxxxxxxxx
Subject
	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.

Back to the top