Re: [platform-core-dev] org.eclipse.core.runtime.Path issue with colons

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

I just tuned into this thread and so
apologize if I recap...

Where exactly are IPath and Path causing
you problems?  They are meant mostly as a utility class for people
wanting to manipulate '/' separated strings (with an optional X: drive
annotation).  They are NOT meant as a replacement for java.io.File
(as much as one might want a replacement).  We were probably overzealous
when including drive letter annotations but they are optional so one can
use IPath/Path quite happily without ever spec'ing a drive letter.  People
wanting to manipulate filesystem paths would be well-advised to use java.io.File
wherever possible.

There are relatively few places where
the runtime exposes IPaths with any consequence.  Is it one of these
API?  If so, which one(s)?

The Resources plugin uses IPath and
Path extensively to define and manage its tree structure.  Here the
issues of case sensitivity and excluded chars becomes very relevant (note
that drive letters are not relevant here).  The resource tree is not
case sensitive because IPath is, IPath is case-sensitive because we wanted
a case-sensitive tree, etc etc.  That is, the path behaviour follows
the behaviour we wanted for the resource tree not the other way around.
 

Why did we want such lowest common denominator
behaviour for the tree?  The resource tree has to handle resources
that come from many different sources.  You might work on Windows,
me on Linux, the next guy on Mac.  We all stash our resources in CVS
(running on some OS).  Then I check out yours, you mine, ...  It
was found through bitter experience that people get quite grumpy when you
munge their resource structures because, for example, a particular char
is special on one file system and not on another.  Similarly for case-senstivity.
 Imagine checking in some duplicate but mixed case names on Linux
only to find that Windows users get only one resource!  

As for changing API, it is not really
about the API as such but more in the current uses of the behaviour (specified
or otherwise). By asking, for example, to have IPath change its sensitivity
depending on the local file system, you would be asking for the resource
tree to become insensitive on Windows but sensitive on Linux.  This
would cause massive problems with existing resource structures.  Similarly
for changes in how path strings are interpreted (special chars etc).

Neither John nor I would want to "shut
you down" but it would be remiss of us to not point out the issues
and challenges.  I for one would happily donate all my +1 powers to
anyone who can come up with a solution which is notably better and can
be integrated in a consistent way so as to not put off vast numbers of
existing plugin writers or Eclipse users.

Jeff

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

08/31/2004 06:54 PM

Please respond to
platform-core-dev

To	platform-core-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-core-dev] org.eclipse.core.runtime.Path issue with colons

I understand taking API contract compatibility seriously,
however I 
wouldn't characterize
this as a flaw, I'd characterize it as a BUG.  My basic tendency would
be to fix the bug, correct
issues in the Eclipse code base that arise from fixing the bug, 
publicize the fix so third
parties can fix their issues and move on.  What sort of issues do
you 
forsee arising from the
proposed contract change other than intolerance of path separator literals?

Ed
John Arthorne wrote:

>
> That is a fairly accurate summary of the situation. If I were writing
> a gripe list about IPath, I would also add the fact that it is always
> case-sensitive, regardless of the underlying file system. This causes
> problems on platforms such as Windows, for example.  Despite
these 
> problems, API contract compatibility is taken very seriously in the
> Eclipse platform, even when that API has flaws.
>
> Ed Warnicke wrote on 08/31/2004 05:45:23 PM:
>
> > OK, let me see if I understand correctly:
> >
> > 1)    IPath provides segmented paths, for this purpose
we
> >        need a path separator character.
> > 2)   We disqualify from path segments all characters that
> >       are used as path separators on known platforms
> >       ('/' and '\\') whether they are path seperators
on the
> >       running platform or not so that in the event
that
> >       someone incorrectly hard codes a literal
(as opposed
> >       to using System.getProperty("path.separator")).
> > 3)   In order to support the drive letter feature on Windows
> >       (and I've still seen no other rationale)
we need a
> >       driver separator character (hard coded as
':').  We therefore
> >       disqualify the character ':' whether the
platform we are on
> >       has driver letters or not.
> > 4)   This causes breakage because it invalidates path segments
> >        that are perfectly valid on POSIXs
compliant platforms
> >        (pretty much everything but Windows).
> > 5)   Because this behavior is part of a published interface
we
> >       are not going to fix it.
> >
> > Is this an accurate summary of the situation?
> >
> > This problem has been open for almost 2 years now... it's only
going to
> > get more painful to fix going forward.  I'm willing to do
the work to
> > fix it,
> > but not if I'm just going to be shutdown for trying to change
a 
> 'published
> > interface' even if that interface is broken.
>

_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev