New "-cargo" option for every Tk widget

TCL users have long been at a disadvantage not having a possibility to attach arbitrary widget-related values (e.g., "tooltip"-texts) directly to widget, being forced to use workarounds (e.g. external variables to hold the data) or even entire additional packages/frameworks (like Snit) exactly because of the lack of the proposed option. So the proposal is "solutions instead of workarounds": let's introduce the option - further named "-cargo" (the name taken from Clipper) - which will cancel the current need for fixes of different kind. The option should allow to access a string field (or even better: a dictionary), allowing to keep there any widget-related data, choosen by script creator. It's value should be accessible both by "cget" and "percent substitution" (like "%C").

In a talk at everyone - or almost everyone - posting in the appropriate threads, appreciated the proposed solution as useful. There were some fears about possible "clashes" while using that option (or that the proposed option will be even "too useful"). I would to mention here, that "cargo" idea has been taken from Clipper, where - during over 20 past years - there is no evidence at all of any "clashes" (neither of any other damage) only because of availability of such option. Being sure, that TCL programmers aren't less skilled than those Clipper guys, I cannot describe such fears differently, than as not reasonable ones. So because such option has been successfully tested in other language (there are no complaints from Clipper programmers about any "cargo"-harmness), there's no need for "prophecies" of the type "it will do damage", because there has been proved exactly the contrary. Some more possible usage gave Bryan Oakley in his post: What sort of data would I potentially keep with a widget? Perhaps an index that points to context sensitive help. Or, I might keep an undo stack, or a copy of the original value. Think of a label widget that automatically truncates it's text and adds "..." if the widget is resized smaller than it's preferred size -- you need to keep the unadulterated original value that you can refer to as the widget grows and shrinks. Better to keep that with the widget than in a global variable, IMO. Or, I could use it to keep track of a "dirty" bit that gets set when the original value of a radiobutton or checkbutton changes. Or I could store a database primary key that points to where the data for the widget came from. I believe, that's not all, because we cannot predict today, what other useful things can be done with option of such "universal" (not "targetted") nature. Two things for sure: a) It'll make the life of every TCL-scriptor easier, b) Its use won't be obligatory, if someone will be afraid of "clashes" possibility, or something like this.