I see now. It's planned that there will be highlighting of unknown classes in the table (as well as code completion, auto-import etc). I think this will eventually fix such problems.
Best regards, Valentin Kipiatkov ----------------------------------------------------------- IntelliJ Software, http://www.intellij.com/ "Develop with pleasure" ----------------------------------------------------------- ----- Original Message ----- From: "Wangjammer5" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 20, 2002 2:04 PM Subject: Re: [Eap-list] Change signature is not changing imports > > > 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 _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list
