On 4/19/20 12:04 PM, David Mertz wrote:
Sure. But what I gave was a simple case. There are all kinds of complications like this person_record being passed around from call to call without actually accessing `.telephone` in a particular scope. Or doing something dynamic with the attributes/keys that won't show up in a `grep telephone`. Or the string telephone occurring lots of times in unrelated structures/objects. Or lots of other cases where lots of name changes makes refactoring more difficult. I mean, I've DONE it, and I'm sure you have as well. Clearly refactoring isn't impossible with different names across scopes... and this goal is one of several in picking names, not the single predominant one.
The fact that the name of the variable changes shouldn't affect the refactoring. If the scope doesn't reference the telephone attribute, then it shouldn't be affected by the refactoring. Yes, the dynamic cases says we need to look for the string telephone as well as the direct reference of the attribute telephone.
The fact that we get telephone showing up in unrelated structures is likely a plus, as if we find that it isn't good enough to store just a single phone number in this sort of record, we likely should be thinking about how we did it elsewhere, especially the way it was described as the data flowing through various forms and not just a single structure.
In some ways this show the danger of coercing the programmer to reuse names for unrelated things, it encourages bad names. The mere fact that the record had a single field called 'telephone', as even decades ago many people had more than 1 phone number, they at least had a home_phone and and work_phone (and later a cell_phone).