On Wed, Apr 22, 2020 at 1:38 AM Rhodri James email@example.com wrote:
On 21/04/2020 15:29, Chris Angelico wrote:
On Wed, Apr 22, 2020 at 12:06 AM Eric V. Smith firstname.lastname@example.org wrote:
That's a good example, Chris. Thanks. I also don't see that a namespace object would buy you much, if anything.
Going with the tersest proposal (twitter=twitter becomes twitter=), we'd save something like 40 characters in the function call in the return statement. I think making a change isn't worth adding more to the language, but of course reasonable people can disagree.
Thanks. But it's really not about terseness. I've already typed more in this thread than I'll probably save over a lifetime of shorthanding. If I wanted shorthands, I'd just use shorter variable names.
Removing duplication removes the possibility of desynchronization.
Now here's the heart of things. We're actually talking about synchronization, which in this case happens to be done by using the same name in different contexts. Sometimes this is a good thing, sometimes not; calling it an anti-pattern is harsh, but it does channel your thinking into tramlines that are not always a good thing. The number of times I've changed "handle=handle" to "handle=medium_handle" as projects have crept...
And if you do, you change it, and it's very clear that you deliberately did so. If it's a change from "handle=" to "handle=medium_handle" then there should be a corresponding change elsewhere in the function, and *no* corresponding change in the API. Conversely, if it's a change from "handle=" to "medium_handle=handle", then you'd expect *no* change in the function, and a change somewhere in the API (maybe a change in the template file or something). Either way, the clear change from shorthand to longhand signals that this was a deliberate change that broke the symmetry, rather than being an accidental failure to rename something.