Closed gunnarmorling closed 4 years ago
Indeed, the scope of renameField
was limited to Netflix's particular need in replacing an old internal logging library with SLF4J. Doing it perfectly would be somewhat difficult (though by no means impossible - IDE's like IntelliJ do it!), because you'd have to track references to that field not only in the class, but subclasses, etc.
I've long been a proponent of "don't let the perfect be the enemy of the good" in these kind of efforts though. If extending renameField
to include references in the same class solves 99% of the problem, let's do that!
it could be a very useful thing for library authors so they can ship refactorings alongside their code, when releasing an incompatible new version of their lib.
This was the original intent!
Hey, thanks for the quick reply. Indeed I'd say adjusting references in the same class would be a great start and cover many cases already. It could be extended subsuquently to also cover external references on non-private fields.
I was playing with the
renameField()
refactoring and assumed applying this would also change all references to that field (at least in the same CU). It seems though I need to apply another refactoring to adjust the target of method calls on that field.In the absence of such feature, what'd be the best way to achieve such refactoring? Is there any example for it somewhere?
Thanks a lot btw. for providing this tool, it could be a very useful thing for library authors so they can ship refactorings alongside their code, when releasing an incompatible new version of their lib.