Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Bug 22905 and API deprecation

A bit of topic, but in my experience, if you provide a Gerrit review instead of a patch you will get faster feedback on the suggested change. See here for a description how to use Gerrit for Eclipse patches: http://www.vogella.com/articles/Gerrit/article.html#eclipsegerritcontribution


2013/11/27 Alexandros Karypidis <akarypid@xxxxxxxx>
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

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev


Back to the top