Bugzilla – Full Text Bug Listing
| Summary: | [rename method] renames wrong method | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Sergey Yevtushenko <sergey.yevtushenko> |
| Component: | UI | Assignee: | Markus Keller <markus.kell.r> |
| Status: | CLOSED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | frederic_fusier |
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
Move to JDT/UI It sounds to be a Search Engine issue as searching for declaration of Zhope.method() in project returns ZhopeBase.method-) as exact match! Finally, problem is in JDT/UI land as it search for declaration ignoring declaring and return types... Perform a search using Java Search dialog correctly returns only one match... => move back to JDT/UI This is a feature, not a bug ;-) The Rename Method refactoring renames all related methods in the ripple (up and down the type hierarchies). If we would not do this, the refactoring would produce compile errors. See also explanation in bug 83293. Although I agree that current solution for #83293 makes sense, this case is a bit different, because a) method in ZhopeBase has a bit different signature and b) there are not two interfaces but base class AND interface. I can even imagine situation when such a splitup (i.e. partil renaming of the methods) may be what is really necessary. Perhaps it worth to add a warning + checkbox and let user decide if to rename all implementations/declarations or just part of them. In case of large hierarchy selecting each class manually might be very inconvenient and error prone. > a) method in ZhopeBase has a bit different signature No, the signatures are the same (no parameters). Modifiers don't matter here (and are actually also equal because interface methods are implicitly public). > b) [..] I can even imagine situation when such a splitup (i.e. partil > renaming of the methods) may be what is really necessary. I agree that this is sometimes necessary, but unfortunately, it can't be done with an automated refactoring. If you have a variable 'ZhopeChild ch' and a call 'ch.method()', then there's no way to tell which method was "really" meant. Agree. But I did mean just warn user about the conflict and let him decide which branch (or both) to rename. Silent operation here is not a best choice. Agree. But I did mean just warn user about the conflict and let him decide which branch (or both) to rename. Silent operation here is not a best choice. |
Consider following hierarchy: -------------------------------- public interface Zhope { void method(); } public class ZhopeBase { public void method() { System.out.println("method!"); } } public class ZhopeChild extends ZhopeBase implements Zhope { } -------------------------------- Renaming method name in interface Zhope renames it also in ZhopeBase, although this class does not implement Zhope interface.