Re: [TCLCORE] About TIPs 727 and 729

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

Hi Emiliano,

See my embedded comments below.


Am 23.09.25 um 03:06 schrieb Emiliano:
> On Mon, 22 Sep 2025 22:18:13 +0200
> Csaba Nemethi <csa...@t-...> wrote:
> 
>> Hi Emiliano,
>>
>> Many thanks for your comments!  See my answer embedded into your text.
> 
> Many thanks for taking the time to read them, and for moving this forward!
> See inline comments ...
> 
>>
>> 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?
> 
> Tk predates namespaces, so compatibility plays an important role here.
> But this is not the case with this functionality, which is meant to be used
> primarily by package developers, so they are expected to put all their data
> inside a namespace.
> 
> That said, even the current docs recommends, in case of images, to use
> namespaces. image(n) reads "It is important to note that the image command
> will silently overwrite any procedure that may currently be defined by the
> given name, so choose the name wisely. It is recommended to use a separate
> namespace for image names (e.g., ::img::logo, ::img::large)."
> 
> I'll argue that, while *named* images should be created from the global
> scope (so they are easier to find), non-named images, as created by
> [image create $type -opt ...] should be created in the current namespace
> as the returned name will be assigned to a variable anyway. Just as
> [oo::object new] does.
> 

The new version creates the attribute table of a given name as a 
procedure in the namespace of the calling context if not fully qualified.

>> 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."
> 
> Sorry, didn't read the docs, just the tip. My bad!
> 
>> 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?
> 
> For the same reason [winfo] returns an error when asked for info about a
> non-existing widget but doesn't when asked about whether it [winfo exists].
> It should return just true or false.
>   

The exists subcommand no longer checks whether the path name specifies 
an existing widget.

>>> * 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" ?
> 
> No. As said, just consistency with [dict set]. While I like consistency, this
> can be left out. Fine with me.
> 

No action here.

>>> * 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?
> 
> Also fine with me. This is also for the sake of consistency. When some
> functionality in Tcl or Tk uses a handle or any kind of mapping, the "names"
> subcommand (array names, image names ...) usually is a list of keys.
> In this case, we have two cascade mappings in play: window -> attributes
> dictionary and attribute (or key, or name ... ) -> value. I simply thought
> in collapsing both in a single command.
> 

Now I have added a pathnames subcommand.

>>> 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.
> 
> Sorry, but I beg to differ on this point. A C implementation is not much
> longer. tkcargo is 466 lines of C code and it actually have more functionality
> than the one proposed here, using standard Tcl and Tk C API. It is also way
> faster, mainly when the number of widgets and the number of tables become
> quite large [1]. I've attached four files, three measuring test scripts and
> a result csv file. The three test scripts are almost the same, one running
> with plain Tk (not tables) to be the reference value, one with [tk attribtable]
> and one with tkcargo. They are different as I just want to be sure I was
> testing the right thing and be sure I didn't srew up things. While the results
> seem somewhat noisy, the tendency is clear.
> 
> Also, I'm not comfortable with the modification of Tk_DestroyWindow to
> support this use case, based on two points. First, the cleanup script
> will be forced to run even for widgets that are not in any table, a source
> of slowdown. And the other is a matter of style: when introducing any other
> functionality which needs to perform some cleanup when a widget is
> destroyed, will we keep adding scripts to run?
> 

This is still open, maybe we should see the opinion of further Community 
members.  The current implementation is straightforward and works as 
expected, but I can understand that you would prefer one in C only.

> Regards
> 
> Emiliano
> 

Thanks again for your feedback!

Best regards,

Csaba

> [1] Result also show something that looks like O(n^2) when detroying large
> number of widgets, for example a frame with several thousand children. But
> this has to be investigated independently of the ongoing discussion.
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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