Re: [TCLCORE] About TIPs 727 and 729

[Csaba N. <csa...@t-...>]

Hi Emiliano,

Many thanks for your comments!  See my answer embedded into your text.

Am 22.09.25 um 17:48 schrieb Emiliano G:
> El jue, 18 sept 2025 a las 16:24, Csaba Nemethi
> (<csa...@t-...>) escribió:
>>
>> As announced below, a few days ago I committed a thoroughly updated
>> implementation of the element creation for ttk::toggleswitch widgets
>> (TIP 727).  The new version contains both generic code for arbitrary
>> themes and theme-specific one for a few built-in themes.
>>
>> Today I committed a revisited version of TIP 729, whose title now reads
>> "Add a tk attribtable command to the core" (the initial one was "Add a
>> tk_cargo procedure to the core").  The new version made it necessary to
>> rework large parts of the implementation, which I committed today, too.
>>
>> Comments on both TIPs are highly appreciated.
> 
> Some comments about tip 729, most of which are personal preferences:
> 
> * tk attribtable tableName
> 
> My preference for the tableName command to be created in the current
> namespace if not fully qualified. This will ease the handling of
> attribute tables when implemented as TclOO objects. If tableName
> already exists, it is overwritten. Also, in all the tableName instance
> subcommands, if pathName doesn't exist my preference is to raise an
> error, except in [tableName exists].
> 

It is common practice in Tk that commands by name are created in the 
global namespace.  Example: image create <type> <name> ...  Here the 
<name> command is always created in the global namespace.  Why should we 
break this rule?

The implementation already makes sure that an already existing tableName 
command will be overwritten.  This is explicitly mentioned in the manual:

     "If an attribute table of the given name already exists then it is 
replaced with the new one and all the attributes of all widgets set 
using the old table instance will be unset."

Also, in all the tableName instance subcommands, if pathName doesn't 
exist then the implementation already raises an error.  This is valid 
for all op names (set|get|names|unset|clear|exists).  Why should the 
"exists" case be handled differently?

> * tableName set
> 
> Preference to return the full key-value pair for pathName in
> tableName, just as [dict set] does.
> 

What would this be good for?  Do you have a convincing use case?  Would 
it have any benefit over retrieving this information via "tableName get" ?

> * tableName get
> 
> Preferred API
> 
>    ** tableName get pathName ?key? ?defaultvalue?
> 
> If there's no such "key" entry, "defaultvalue" is returned if
> specified, or an empty string otherwise, just as [ttk::style lookup]
> does.
> 

OK, this is a decent proposal, I will implement it.

> * tableName names
> 
> Preferred API
> 
>    ** tableName names ?pathName?
> 
> returning the list of path names in tableName if pathName is not
> specified. Otherwise, it returns the list of keys already set for
> pathName in tableName.
> 

Here, the word "names" always refers to attribute names, aka keys.  Your 
proposal would add a second meaning to it.  What about a new subcommand 
"tableName pathnames" instead?

> * tableName clear
> 
> I prefer the description "Unsets all attributes *and removes pathName*
> from tableName. Returns an empty string."
> 

OK, I will add this to the man page.

> About the implementation: is there any technical advantage to do this
> in Tcl and not C?
> 

The implementation in Tcl is much simpler and easier to maintain. 
Currently it has no more than 228 LOC, of which 81 are comments or empty 
lines.

> Regards
> Emiliano
> 

Best regards,

Csaba

> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...