| [e4-dev] [resources] draft patches posted for EFS physical operations |
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