This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 101242 [details] screenshot Have a look at the attached screenshot, refactoring finds also a method with the same name but in a different class (and wants to change it in case of rename). Also please notice that the icon is incorrect (I mean the Java package icon). Thanks. Product Version: NetBeans IDE Dev (Build 100805-f7d53dfaea6b) Java: 1.6.0_20; Java HotSpot(TM) 64-Bit Server VM 16.3-b01 System: Linux version 2.6.32-24-generic running on amd64; UTF-8; cs_CZ (nb)
http://hg.netbeans.org/web-main/rev/33e54a70579f
Sorry, this one is the right one: http://hg.netbeans.org/web-main/rev/a50c44758a5b
Integrated into 'main-golden', will be available in build *201008100001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/a50c44758a5b User: Radek Matous <rmatous@netbeans.org> Log: #189267 - Rename refactoring changes also unrelated methods
I am experiencing almost the same problem: I tried to rename method defined in the interface expecting to get only collection that will contain only methods overriding method in question. Instead I am getting all methods having the same name regardless if those methods are overriding method in question. Same applies to renaming class methods: In results will appear usages of all methods having the same name regardless of defining class as in original example.
Please evaluate, thanks.
It's reproducible, but I think that that's the reason, why there is a forced "Preview" window to check what to rename, that you can't simply confirm a new name and break all "possible" method names. I think that it will not be so simple to fix that, but since there is a "preview for check" view, it's not a P2...common P3 for me. I'll try to look at it for 7.2, but as I said...:/
I'm trying to improve it a bit, but the more I look at it the more I think that it's a good feature. Because if you have a poorly documented code (no return types in PHPDoc and such), then we can't clearly resolve the proper methods. I can imagine a code, where will be some method call on a dynamicly typed object, so then we really can't know if it's "that method you want to rename", or "some another method of the same name". So what should we do? Don't suggest that method, because its type isn't exactly that type you wanted to rename? Or suggest "all possible method calls" and let you choose the right ones in the preview window? I think that the second option is the most correct. Since PHP is not strongly typed, no "exact" correct selections could be responsibly done.
The another thing, why the current behavior is the right one: The possibility of "breaking users code" (by wrong refactoring...that you don't rename all proper methods) is on user side. USER has to select all proper methods to rename in a preview window. It's his responsibility. If we'll apply the first option (that only "pure exact" methods will be displayed), than the breaking is on NetBeans side and user can't do anything with that...because rename action simply doesn't suggest all methods...because it doesn't know if they are correct. And it's definitely wrong, I think. So thinking about closing this issue as wont fix.
Won't fix. We are not able to handle dynamic calls properly. The best solution is to offer all possible method calls and user selects that calls, which are really valid.
*** Bug 213436 has been marked as a duplicate of this bug. ***