[platform-core-dev] Re: IFile that corresponds to a logical view.

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Thomas Hallgren <thhal@xxxxxxxxxxxxxx> wrote
on 27/07/2005 06:54:59 AM:

> Other solutions than using an IFile are possible of course (something
> similar to the Classpath container visible in the package explorer
for 
> instance) but I think we have a good match for a "logical"
entity in the 
> resource tree.

The Java model is a good example of a logical domain
model with a non-trivial mapping to the physical workspace level.  Having
a specialized view that knows how to display that logical model is of course
the usual approach, but you lose all the capabilities that come along with
being an IResource: markers, other metadata, resource change events, etc.
 For example, external JARs on the classpath do not map to any IResource,
which means classpath errors cannot be attached to them (they are instead
markers on the project), and there isn't a good mechanism for detecting
and responding to changes to those external JARs.

>> I think it ends up being an all or nothing proposition.  As
soon as an 
>> IResource is introduced that has no direct mapping to the local
file 
>> system, the whole platform needs to adhere to that new abstraction,
or 
>> things would simply stop working.

> If that's the case and if I'm the only one that would like to have
this, 
> perhaps such a proposal is a bit unbalanced (resources spent versus
the 
> gains). I wasn't aware that the platfrom was that dependent on the
> physical mapping.
> 

You're certainly not the first to ask, so I suggest at least capturing
your request with a bugzilla entry.  The risk/reward is difficult
to capture.  Many existing users of IResource build in the assumption
of direct mapping to the local file system, although they were somewhat
weaned from that dependency with the introduction of linked resources in
Eclipse 2.1.  On the other hand, there is a large space of potential
new clients of IResource if the assumption of direct physical mapping was
removed. My "all or nothing" comment was a bit disingenuous -
there is a possible path forward where clients that rely on the old behaviour
would continue to function as long as the 1-1 IResource to local file mapping
is maintained.  Meanwhile new clients built to the newer assumptions
could operate on both "physical" and "logical" IResource
objects.  The two worlds need not necessarily intersect.