Rename (refactor) and finding usages seems completely unusable because NetBeans is using trying to find method calls, instead of using his "auto-completion" data.
Is it possible to introduce two methods of refactoring (find usages)?
1. Strict - if NetBeans is not sure (no docblocks), method will be not listed when refactoring.
2. Flexible - NetBeans will just search for any calls like it's doing right now.
1. Find usages finds methods both classes: http://d.pr/i/RFdt
2. Preview of renaming method: http://d.pr/i/g5hJ
public function testRename()
public function testRename()
Sorry, but it's not a defect...it's an expected behavior. Your "strict" refactoring is quite useless and will lead to broken code...some parts will be refactored and some will not. So the better way is to suggest "all possible methods" (remember some dynamic calls and such) and user is the one, who will choose what to refactor...
But I'll let this issue open...just as an enhancement reminder. Thanks for your response!
Thank you for response! Right now with current implementation is hard for me to use that feature. Maybe just a little information like "green" (for strict) and regular "black" font color (for any result) to indicate if NetBeans is "sure" about the displayed usage would be great!
Unfortunately NetBeans can't be never sure...if you make a typo in a PHPDoc, whole refactoring could be broken. It can't be checked in "compile time" so almost everything "could be wrong". It's the general problem of all "non-type-strict" languages...:(
Yeah but relaying on docblocks is the only "good enough" choice. IMO search for method calls of the same name across the project is insane! I have more than a 1200 calls of `getName()` method across the codebase. How I can refactor and rename in one class this `getName()` to `getOperationName()`? It's impossible! It's better to relay on docblocks - people know that editor can't find every possible usage of the method - it's dynamic-typing languages and everybody knows that. Process of refactoring should be 2 steps: first using docblocks then using search as fallback.
(In reply to comment #4)
> It's better to relay on docblocks - people know that editor can't find every
I know that, you know that...but it doesn't metter. Even though most of people know that, most of them will complain if we will not suggest "everything" what we should. One call will be missing in the result and people will shout on us :) Trust me that it's not so simple as it looks like ;)
But I agree that whole "refactoring process" should be somehow more clever, definitely.
Yes, I agree. The process should be more clear. For me rename and find usages it's the only weak side of the editor. Everything is polished, seems great - only this refactoring acts a little weird.
I would support having strict and louse refactoring modes.
Current mode is occasionally useless. Try finding usages of method MyClass::init() when working with Zend Framework. You will get completely trashy results. I know that the given example is a bit extreme but it's meant to illustrate the point.
I do understand your points on PHP "louse" nature but there are developers who prefer strong type casting and code in such way. Please support us and give us option to use find usages and/or rename refactoring in a strict mode.
Interesting addition would be to be able to filter-out list of found files by directory hierarchy.
Imagine that example with `init()`, the result could be displayed in a tree:
This feature would allow to just click on [delete from the result set]. So by just clicking [delete] on "Zend/" we would be able to skip a huge amount of invalid cases found by the louse "refactoring method". Above feature would be extremely useful for me everywhere in NetBeans. I could just delete which I don't want to see, like "search" results which were pointing to places which I've wanted to refactor. After changing the code I would [delete] the entry from result set to indicate what I did already and what I didn't.
Additionally as I said before, simple filter to [delete] all results that are non-strict would be amazing.
*** This bug has been marked as a duplicate of bug 218660 ***