[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[platform-ui-dev] Bug 22905 and API deprecation
|
Hi,
I've been working on bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=22905 and the recent
discussion among Lars and Daniel regarding the API deprecation policy
(see http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg05512.html)
has caused me to stop. I've been changing stuff in
org.eclipse.ui.IFileEditorMapping and org.eclipse.ui.IEditorRegistry
rather irresponsibly.
Now, the problem with this bug is that it requires a bit of change in
semantics. Very briefly:
People want to be able to associate editors with extensions that contain
dots like so:
*.x.y.z --> xyzEditor (so "file.x.y.z" and "other.file.x.y.z" would
open with xyzEditor)
*.z --> zEditor (so "file.y.z" and "file.z" would open with
zEditor)
Currently we define the "extension" to be everything after the LAST dot
character, so this is impossible. If you try to add a file type with
value "*.y.z" it is rejected (there can only be one dot in the pattern,
or it is considered invalid).
*.x.y.z --> xyzEditor (so "file.x.y.z" and "other.file.x.y.z" would
open with xyzEditor)
*.z --> zEditor (so "file.y.z" and "file.z" would open with
zEditor)
One way to go at this is to keep the API identical and change the semantics:
1) Redefine the "extension" concept to be everything after the FIRST dot
2) When looking up mappings for some filename, sequentially relax the
extension until a mapping is found (e.g. file.x.y.z will look for
mappings for *.x.y.z, *.y.z and *.z -- in that order -- and stop at the
first matching mapping as the most specific mapping should "win").
This semantic change would in fact mean the API is backwards compatible:
currently there are only simple rules in the wild (*.somextension), so
changing the existing API implementation along these lines would mean
things will keep working (but people will be able to now add more
specific rules going forward).
Another way to have a go at this would be to introduce a new "suffix"
concept which is everything after the first dot. Then
IFileEditorMapping.getExtension() and IFileEditorMapping.getSuffix()
would return different things. New constructors could be added to create
suffix-based mappings (new behavior) and
IFileEditorMapping.getExtension() would be deprecated (along with
existing constructors in the internal implementation which are based on
the extension concept).
I am uploading a patch to the bug (currently works for me) but I would
like some pointers on what the best way forward would be. Should I keep
on adding this "suffix" stuff or is it better to just change semantics
in a backwards-compatible way (which maintains the current API signatures)?
Cheers,
Alex