Community
Participate
Working Groups
Start with a class like this: ----- class Foo { int bar0; void setBar(int bar) { bar0 = bar; } } ----- Now, using the refactor..rename command, rename the class variable "bar0" to "bar". There will be an error message that pops up: "Problem in 'Foo.java'. Another name shadows access to the renamed element However, in this case there's an easy fix for this. Simple change the reference inside the method from "bar" to "this.bar" So, the refactored code should look like this: ----- class Foo { int bar; void setBar(int bar) { this.bar = bar; } } -----
I hit this bug today and was suprised at its existence when the fix seems fairly simple (to the uneducated :-) ). It seems dangerous that a refactoring procedure can be left in a situation where it will cause a change in system behaviour. The warning helps but a fix would be nicer. The insertion of the "this" keyword seems sensible to me. Eclipse3 Milstone8.
*** Bug 140201 has been marked as a duplicate of this bug. ***
no plans for this at the moment
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
Is there any news on this bug. This bug is often encountered in the use case of incrementally from a naming convention where fields are prefixed (e.g. m_MyField) to a naming convention where they are not (myField). That would be nice if it could be fixed.
Implementing this would conflict with and weaken the settings "Local variable declaration hides another field or variable : Warning" and "Use 'this' qualifier for non-static field accesses : Only if necessary" that I use to prevent accidental name reuse. As a workaround, Source->Clean Up... can be configured with "Use 'this' qualifier for non-static field accesses : Always" to add them only as needed while fixing those kinds of bothersome naming conventions.
For the case where this setting is defined to Ignore or Warning it could still make sense to allow the refactoring maybe with an additional parameter allowing to specify strategy in case of shadowing: "Prefix By this." or "Fail Refactoring".
Markus, Sebastian seems to we interested to work on a patch. Do you think this RFE could be revived following his suggestions?
We should keep showing a non-fatal error, but we could change the refactoring to insert "this." instead of producing a shadowing. We won't add a setting to insert "this." silently. I'm not sure if we already create an AST for this refactoring. If not, then the implementation may not be trivial, which makes it less likely that we would accept a patch.
Hi, I spent some time to understand how the renamed of field worked. From what I understand to update the references the RenameFieldProcssor does the following high level steps: * Use the RefactoringSearchEngine to find the references to the field * Update the references by replacing the old name by the new name at the "positions" returned fo each reference * Computing a new list of references to the field with the new name after the update (using RefactoringSearchEngine) and check that they match the old references. If there is some discrepencies it deduce that some shadowing happened and raises an error. So basically the shadowing is detected after the fact so we cannot easily detect when "this." prefix would be needed. I guess fixing this bug would require to change the implementation to compute an AST of the compilation unit referencing the field to detect the potential shadowing beforehand right? Was it what you were refering to Markus? Is there another refactoring that would use a similar technique that I could use as an example?
