Summary: | [Databinding 2.0] Collections inheritance is inconsistent | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Christoph Laeubrich <laeubi> |
Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | jens |
Version: | 4.14 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 566750 |
Description
Christoph Laeubrich
2020-09-08 00:30:20 EDT
As disccused in Bug 566755 it is not really possible to do breaking changes and major versions has to remain the same forever, I'll thus propose to add a new package named > org.eclipse.core.databinding.observable.collections that includes cleaned up versions of the collection implementations with new semantics and old classes can the be removed via the 2-yers removal process afterwards. Hello Christoph, It is nice that you want to improve the databinding framework. I agree that the design would be better if it were the way you describe. I too think it is frustrating to be forced to keep old, defect API:s for backwards compatibility. But breaking backwards compatibility has a very high cost for library API:s like this. If we were to remove old classes even after 2 years it might break useful plugins that are no longer maintained but have been working fine for years. My feeling is that even if your suggested changes would be useful improvements, they would not be useful enough to justify the cost. In any case, that not a decision I can make myself, someone in a responsible position within the project would have to get involved. Is there *anything* we could do about the code duplication between ObservableList, AbstractObservableList and DecoratingObservableList without breaking backwards compatibility? An example of removed API elements that cased problems turned up on the platform-dev mailing list recently: https://www.eclipse.org/lists/platform-dev/msg02397.html |