I have worked up two draft solutions to logical vs. physical EFS issue.
Both draft solutions are API
compatible with 3.5. Both probably require some cleanup before they would
be
comitted (e.g. cleanup @since tags).
The patches are currently against the e4 repository but could be trivially
reworked to go into 3.5.
Approach 1:
===========
This approach declares a new interface, IFileStore2, which provides new
APIs
which specifically provide either "logical" operations (i.e. as the
workspace
sees the resources) or "physical" operations (i.e. as the operating system
sees
the resources). Previous methods on IFileStore which were ambiguous (and
thus,
were defacto logical operations) are deprecated.
Pros: Ambiguous APIs are explicitly discouraged. Easy for API consumers
to
figure out what they should be using instead (e.g. all implementations of
IFileStore in the platform would now implement IFileStore2, which readily
shows
up in things such as Type Hierarchy).
Cons: More code changes were required in order to provide new
functionality in
a non-breaking way.
Approach 2:
===========
This approach declares a new interface, IPhysicalStore, which encapsulates
the
physical operations from Approach 1 into their own interface. IFileStore
is
unchanged, and logical operations are not explicitly defined (logical
operations remain the purview of the ambiguous APIs in IFileStore).
Implementations of IFileStore in the platform become adaptable to
IPhysicalStore.
Pros: Less code changes required.
Cons: Ambiguous APIs remain. Difficult for API consumers to know that
they
should be adapting to IPhysicalStore where applicable (consumers are
unlikely
to notice usage of IPhysicalStore unless they happen to inspect the code in
GetAdapter()).
There is a possible third approach, if this work were solely going to
appear in
e4, namely, that the new APIs could be added directly to IFileStore, and
the
ambiguous APIs removed altogether, but as that would be a breaking change I
have not gone down that path, as I am hoping this could make it into 3.5.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=215261 for the patches.
Feedback is appreciated.
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev