> I cannot reproduce this behaviour. If the type is imported in the file
where
> the original method is located, imports should be added to all other
files
> where required. Could you please describe you problem with more details?
Sure. I think I have narrowed it down too. It only happens when:
1. you are changing a parameter (or return) type of a method
2. the method is in a interface/class that extends/implements a
superclass/interface
3. you invoke the Change Signature refactoring in the DERIVED
class/interface file (or in a usage), and answer "Yes" to the "Do you
want to refactor this method in the superclass/interface" question.
4. the file containing the base class/interface for the refactoring does
not have an "import" statement for the new type of the return /
parameter, whereas your derived class does.
So basically you could say that this is not a bug, but it is certainly
confusing.
If the superclass/interface file contains the import already, the
refactoring is done properly. However, if the derived class contains the
correct import, but the superclass/interface does not, it does not add
the import to all the affected files.
A complete example:
---some/package/DerivedClass.java---
package some.package;
import some.other.package.NewType;
public class DerivedClass implements TestInterface
{
public void testMethod( String s) { }
}
---some/other/package/NewType.java---
package some.other.package;
public interface NewType
{
}
---some/package/TestInterface.java---
package some.package;
public interface TestInterface
{
void testMethod( String s);
}
Now, open DerivedClass, position the cursor on testMethod, and CTRL-F6.
Answer YES to the question. Then in the refactor dialog, change the
String parameter to a NewType parameter. Apply the refactoring.
TestInterface will not compile now due to a missing import. This doesn't
look like a big deal, but when you do a refactoring like this and there
are 20 files affected, it's a pain in the ass!
So it's clear the problem is that the programmer "knows" that the derived
class they are editing has access to the type, but IDEA forgets this when
it moves the refactoring up to the superclass.
Perhaps this also highlights a wider problem of changing parameter types
when refactoring... shouldn't IDEA scan the project (then classpath) for
classes of that Name and be 100% sure of the type the programmer means
before it goes and applies the refactoring?
Hope this helps.
Marc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ W<A> ~~~~~
(o) Wangjammer5 (Marc Palmer)
( ) Wangjammer7
www.wangjammers.org = Java Consultants (Web|Smartcards|Crypto)
_______________________________________________
Eap-list mailing list
[EMAIL PROTECTED]
http://www.intellij.com/mailman/listinfo/eap-list
