Handle assignment to shared object in Lint/UselessSetterCall #7309
Conversation
There are several cases that will trigger Lint/UselessSetterCall when mutating a non-local object.
When a local variable is assigned to a shared object, the referenced object is effectively no longer local, so calling a setter method on it might very well be useful and should not be reported as an offense.
|
What's the high level idea to discern a non-local object from a local one? Looking at the tests - those examples could have just as easily been non-shared objects as well. |
|
The idea is that setting something inside a method-local object is useless but if the object can be accessed from outside the method, then the setter call might be useful and shouldn't be reported.
We can only detect that |
|
@bbatsov Did that answer your question? I tried to clarify, but maybe I'm missing something. |
I don't think we can actually detect this - we can only assume that it's an object that's accessible outside the method. After all you can't know if a method returns some shared object or something else, right? |
|
I see what you mean now, and you're right. We're can't know if it's a shared object. But it could be and we want to err on the side of caution and avoid false positives at all costs. So I want to keep the logic as it is but maybe clarify in the code about the possibly shared objects? |
|
I honestly don't know. I'm leaning towards just ignoring that problem and leaving the code as it is. I don't think that many people ran into that particular issue anyways. Perhaps we should just document the shortcomings of the cop better? |
This closes rubocop#7309, which was an attempt to fix false positives with code. It was deemed too complex, so we're adding documentation for a, hopefully, very rare problem.
This closes rubocop#7309, which was an attempt to fix false positives with code. It was deemed too complex, so we're adding documentation for a, hopefully, very rare problem. The cop configuration now marks the cop as "not safe".
This closes #7309, which was an attempt to fix false positives with code. It was deemed too complex, so we're adding documentation for a, hopefully, very rare problem. The cop configuration now marks the cop as "not safe".
When a local variable is assigned to a shared object, the referenced object is effectively no longer local, so calling a setter method on it might very well be useful and should not be reported as an offense.