Community
Participate
Working Groups
ObservablesManager.runAndCollect has a note that says the following: > As of 1.2 (Eclipse 3.5), there are unresolved problems with this API, see bug 278550. If we cannot find a way to make this API work, it will be deprecated as of 3.6 This problem should be investigated and the note either removed or the method deprecated.
Ticket on the problem which the note is about: Bug 278550
I have examined the discussion on bug 278550 and the patches that were applied to find out if the note on method ObservablesManager.runAndCollect mentioned in Comment 42 is still valid. It seem like after the patches were applied the note is *not* valid, and the problem it warns for seems to be solved. I will remove the note.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166189
On a second thought... It is probably best to deprecate ObservablesManager.runAndCollect. It turns out that not all databinding classes has been updated to hide their internal observables using ObservableTracker.setIgnore. (Such as ObservableCollectionContentProvider.) And more generally: It is really easy to forget to hide internal observables. Also client code that create observables must use setIgnore to avoid problems. This seems to be so error prone that it is best have users not to relay on runAndCollect. I plan to deprecate runAndCollect, and instead add a method addContext as part of bug 287247. I think the new method works for almost all cases, and is much less error prone.
The method might still be useful e.g. if someone likes to have something similar like side effects. I don't know if there is a real alternative then.
(In reply to Christoph Laeubrich from comment #5) > The method might still be useful e.g. if someone likes to have something > similar like side effects. I don't know if there is a real alternative then. I'm about to finished this work. I'm trying to understand what you mean, Christoph. Do you mean that ObservablesManager.runAndCollect should not be deprecated? In that case, can you explain a little more about the use case the method have?
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/189173
I just remember that I once used that for very low level API calls to get similar effects as SideEffect do but without a SideEffectFactory. But maybe its just a confusion because of all the similar named items, so you are talking about org.eclipse.core.databinding.ObservablesManager.runAndCollect(Runnable) but org.eclipse.core.databinding.observable.ObservableTracker.runAndCollect(Runnable) will remain? Or should both be removed/deprecated? I think this method is only interesting to track created observables (what will not be included when org.eclipse.core.databinding.observable.ObservableTracker.runAndMonitor(Runnable, IChangeListener, IStaleListener) is called?
(In reply to Christoph Laeubrich from comment #8) > But maybe its just a confusion because of all the similar named items, so > you are talking about > > org.eclipse.core.databinding.ObservablesManager.runAndCollect(Runnable) > > but > > org.eclipse.core.databinding.observable.ObservableTracker. > runAndCollect(Runnable) > > will remain? Or should both be removed/deprecated? This bug is only about ObservablesManager.runAndCollect, which is only used to dispose observables. ObservableTracker.runAndCollect is not affected. That is a much more important and widely used method.
(In reply to Jens Lideström from comment #9) > (In reply to Christoph Laeubrich from comment #8) > > But maybe its just a confusion because of all the similar named items, so > > you are talking about > > > > org.eclipse.core.databinding.ObservablesManager.runAndCollect(Runnable) > > > > but > > > > org.eclipse.core.databinding.observable.ObservableTracker. > > runAndCollect(Runnable) > > > > will remain? Or should both be removed/deprecated? > > This bug is only about ObservablesManager.runAndCollect, which is only used > to dispose observables. > > ObservableTracker.runAndCollect is not affected. That is a much more > important and widely used method. Okay then sorry for confusion. I must admit I never dispose observable directly, should they not get automatically GC'ed once the go out of scope and no one reference them anymore?
> should they not get automatically GC'ed once the go out of scope > and no one reference them anymore? Yes, they are. But if you for example bind them to GUI elements and the GUI lives longer than the observables, then you have to dispose of them manually or they'll linger. Another case is if you bind to platform services using WorkbenchProperties. But most of the time it should be fine to just let them be GC:ed. I'm not 100 % sure either exactly when you have to dispose them manually...
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/189173 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b5d662dd527cd39210a0d1bb53d426e024dd99d6
I have merged the deprecation note. Anything left here?
(In reply to Karsten Thoms from comment #13) > I have merged the deprecation note. Anything left here? No, done! Closing.
