Tk Source Code

…e.g. by using eq/ne, rather than using e.g. ==/!= or [string match win* …].

(Have only done this so far for comparisons against [tk windowingsystem]; there are probably many more…)

The suggested changes, except for the one in library/demos/widget, have since been made anyway in [d2d8281f24cc] (library/demos/menu.tcl, tests/menubut.test, tests/text.test, tests/unixWm.test, tests/winfo.test) or are obsolete as of [c357edcff224] and [13ceb0aa6a27] (ftests/canvImg.test, tests/image.test).

> Seeing as there were existing check-ins for whitespace tweaks and other
> non-functional improvements, I didn't immediately think this patch would
> be considered disruptive.

I'm also fighting against white space changes, end of line blanks removals and so on. Those can however be filtered out when diffing, so I more or less abandoned this lost cause but I consider them also very annoying.

My goal is to break two rules:

• Don't fix what isn't broken.
• There is more than one way to do it.

Seeing as there were existing check-ins for whitespace tweaks and other non-functional improvements, I didn't immediately think this patch would be considered disruptive. I will go ahead and consider these rejected, and will consider finding a bigger problem to work on.

• eq/ne over ==/!=: what came to mind was expr documentation's suggestion to use eq/ne for string comparison (where Tcl < 8.4 compatibility is not required). Though if I read it more carefully now, the suggestion is specifically regarding cases where the operands are possibly numeric (which is not the case for these examples, since one operand is never numeric), rather than in all general cases. There is likely no observable performance improvement from this, as these are not in any performance critical loops. Nor do I get to argue this change would be for consistency with the rest of the code, as there are still hundreds of other instances of unambiguous string comparison using ==/!=.

• To me, the condition in if {[string match win* [tk windowingsystem]]} comes across as more paranoid than proactive (as if it erroneously anticipates "win64" becoming an option), so I care more about this one instance being changed to a more idiomatic form: if {[tk windowingsystem] eq "win32"}. But I don't know that the demo/library code should "lead by example", nor whether adherence to "idioms" supports that effort and/or is good in itself.

What does the proposed change bring as an added value?

I tend to view such change as unnecessary noise in the files history.