Community
Participate
Working Groups
I was having a look at the databinding code and noticed there was an IDiff. The name of this implies comparison (e.g. Compare as a DiffNode and Team has an IDiff for decribing the difference between two elements or trees being compared. Perhaps IChange would be a better name. I also noticed that the interface had no methods. Doesn't really seem like having it buys you much. Yes, you can only use IDiffs with the binding event but clients would still need to look for a specific type of diff. Also, in talking to Boris, I think the intent is to not allow clients to implement the interface. The javadoc should spec this.
As of 3.3M5, it appears that this interface is not used anywhere. The generic ChangeEvent does not provide a diff at all, and all of the subclasses use specialized variants like ListDiff. I suggest that it be removed entirely to simplify the API.
It is only referenced from BindinEvent, which I would ike to remove too.
IDiff can be removed once BindingListener/BindingEvent has been removed (see bug 175840).
I would prefer not to lose IBindingListener, but I don't think it blocks removing IDiff. The only difference IDiff makes (as opposed to typing the diff field as Object) is to prevent arbitrary data from being set in the field and to document the possible value types. For consumers of the field's data, it does not provide anything that a Javadoc comment cannot. For the framework, it provides a very minor safety check. Note that the diff field itself can be valuable, since computing a ListDiff is expensive. (I've never needed it myself, though.) If you dislike untyped fields, it's probably better to keep the IDiff type than to lose IBindingListener or the diff field.
+1
Fixed by removing IDiff. Released >20070312.
Verified in I20070322-1800
