Community
Participate
Working Groups
I200412081200 We tried to replace our TypeRules#canAssign(..) method by ITypeBinding#isAssignmentCompatible(..). This resulted in many test failures in UseSupertypeWherePossibleTests and ExtractInterfaceTests. The reason is that isAssignmentCompatible(..) doesn't work corrctly with bindings that are isEqualTo(..), but not identical. E.g. in UseSupertypeWherePossibleTests.testNew7(), we call isAssignmentCompatible with two type bindings for the same type p.B (isEqualTo == true, but not identical) and get false as result. We reverted TypeRules to our old implementation in HEAD.
Could you provide a test case?
package p; class A implements I { public void m(){} void f(){ A a= new A(); a.m(); } } interface I { void m(); } --------------------------- - Select type A and choose Refactor > Use Supertype Where Possible - select I and press OK => With jdt.ui from HEAD or from I200412081200: correctly rewrites type of a to I. - change body of TypeRules#canAssign(ITypeBinding, ITypeBinding) to return typeToAssign.isAssignmentCompatible(definedType); => "The refactoring does not change any source code".
Markus, that is the expected behavior. Both bindings have to come from the same batch. I will update the spec to clarify this.
Jerome, but then the API isn't very useful for us. Not all the binding we have are from the same batch. Ensuring this will be a major rewrite and not always possible since we reuse the cached AST from the editor in various cases which will be definitelly from a different batch.
Why do the bindings have to be from the same batch ?
May be IBinding#isEqualTo(...) can help here.
Leveraging binding comparisons to work across contexts is quite hard to achieve; since binding rules are relying on identities (on compiler side) and we do not want to duplicate all algorithms. We could remove #isEqualsTo (btw: it feels like it should have be #equals). And rather make it clear that comparisons are meant to work on bindings within same context. Now we should investigate offerring instead a way to reobtain a binding in a given context (from a possibly remote one): - surface the binding context - allow it to query for a 'relocalized' binding
Defer
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
The right way to solve this problem is to offer an open bindings environment (bug 150657), where ASTs/bindings can be created on demand in the same environment.
*** Bug 120471 has been marked as a duplicate of this bug. ***
