Community
Participate
Working Groups
Build Identifier: 20100218-1602 (Galileo) org.eclipse.core.internal.databinding.property.value.SimplePropertyObservableValue.doGetValue() has a call to notifyIfChanged() which, at times, fires off value change events to its listeners. This has undesired results when all I am looking at is getting the current value. Should such actions be even done in a 'getter' method? Here is the scenario where I faced the problem: I am querying the IObservableValue for its value in an IChangeListener used in org.eclipse.core.databinding.observable.IObservable.addChangeListener(IChangeListener), and I get the undesired behavior that some other databound model is modified when I am just querying for a value. And a possible solution, if the issue is a valid one: I didn't look at the code too deep, but should the call to notifyIfChanged() in SimplePropertyObservableValue.doGetValue() be replaced by this? (If all that is needed is to keep the cached value up-to-date) cachedValue = property.getValue(source); Reproducible: Always
If the issue is deemed to be a valid one, and if the solution I specified is acceptable, I can provide a patch for it, along with a test.
This behavior is by design. This works around a shortcoming where certain observables / properties have no listener API, and so can be modified without our observable ever knowing about it. Therefore we make a best effort inside SimplePropertyObservableValue (and friends) to pick up on property changes that happened outside the control of the observable, and fire those change notifications as soon as we learn about the change. This is the only way that any bindings from any of unwatchable properties could function. You can query any property value without side effects by using the IValueProperty instance directly: Object currentValue = property.getValue(source);
Marking wontfix. Current behavior is by design, and this behavior can be worked around by using IValueProperty.getValue(obj) instead of IObservableValue.getValue(). If it can be demonstrated that this behavior is generally harmful then I'm happy to reconsider, however from your comments it appears that the above workaround would suffice.
