Community
Participate
Working Groups
The Javadoc of IBindings#equals(Object obj) tells how clients should compare IBindings. Is there a reason why the equals method is not implemented in implementations of the interface? JDT UI currently uses an equals(IBinding b1, IBinding b2) method in an internal helper class to achieve the desired behavior. However, we cannot e.g. put bindings into a HashSet, because bindings from different clusters are not considered equal.
As spec'd, bindings are inexpensive for clients that are only dealing with one cluster of them. These clients do not need keys (IBinding.getKey()). Judging equality between clusters of bindings involves computing keys, which is somewhat more expensive. This is why more complex comparisons are left to clients rather than being built in to IBinding.equals(Object). Is the inconvenience to clients severe enough to change how this method is spec'd?
Refactoring typically deals with clusters of bindings. So we wrote special equals methods which we use all over the place. Currently putting bindings into sets or hash maps isn't possible.
We discussed this during the JDT meeting in ZRH and came to the following concolusion: Binding will provide a method isEqualTo which isn't based on identity (to not break the spec). We already have our own implementation of a hash table which delegates equals and hashcode to a strategy.
Olivier, Assign to me and I'll take care of spec.
Added IBinding.isEqualTo(IBinding binding) and implementation. Olivier, please add appopriate tests. Thnx /** * Returns whether this binding has the same key as that of the given * binding. Within the context of a single cluster of bindings, each * binding is represented by a distinct object. However, between * different clusters of bindings, the binding objects may or may * not be different objects; in these cases, the binding keys * are used where available. * * @param binding the other binding, or <code>null</code> * @return <code>true</code> if the given binding is the identical * object as this binding, or if the keys of both bindings are the * same string; <code>false</code> if the given binding is * <code>null</code>, or if the bindings do not have the same key, * or if one or both of the bindings have no key * @see #getKey() * @since 3.1 */ public boolean isEqualTo(IBinding binding);
I don't see what that method is adding. This is simply a convenient method to compare the keys. This could clearly be done by the users and it doesn't need to be provided as an API. As you said, you already have code to handle comparison not based on identity. So why adding this new method? When such things are discussed, I'd like to join the discussion.
Philippe mentioned that generating the key isn't cheap. So he suggested that the method can be implemented using binding internals (instead of using the key). We do lots of binding comparisons outside of hash tables.
Too late for M2. Changed milestone to M3.
The method has already been added for M2. A more optimized implementation will be provided for M3.
Version that is not creating the keys is released. Fixed and released in HEAD. Regression tests added.
Verified for 3.1M3 with build I20041101
