Re: [TCLCORE] On namespace unknown and TIP 689

[Poor Y. <org...@po...>]

On 2025-08-01 15:46, Dipl. Ing. Sergey G. Brester wrote:
> 01.08.2025 07:43, Poor Yorick wrote:
> 
>> Tcl already has such a feature, and it's even already got a reasonable
>> 
>> name: [namespace ensemble]. This stuff was all already thought-out,
>> discussed, and added a long time ago. [namespace ensemble] exists to
>> provide the more dynamic features of a namespace. [clock] is a
>> namespace ensemble command, and [namespace ensemble] is a beautiful
>> way to implement it. Sergei doesn't want to use [namespace ensemble]
>> because apparently it takes a microsecond or two longer than the way
>> he came up with. In TIP 689 I there is already a link to the
>> implementation of clock that I provided, showing that this can already
>> be done more cleanly with [namespace ensemble]. A new "expando"
>> procedure would amount to a second implementation of [namespace
>> ensemble] phrased slightly differently, and the only benefit would be
>> that the new idiom would currently be microscopically faster than the
>> [namespace ensemble] way. I suggest focusing on optimizing [namespace
>> ensemble] instead. Tcl should ditch the namespace-ensemble-avoiding
>> implementation of the clock initialization routine, and should not
>> reimplement [namespace ensemble] as [expando]. Doing so would
>> enshrine a hack that was used for dubious reasons as part of the Tcl
>> public interface, and lead to endless questions about whether to use
>> [namespace ensemble] or [expando].



> You're trying to mix bananas with cucumbers, again...
> You might wonder, but THERE ARE NAMESPACE WITHOUT ENSEMBLES! A LOT!
> I'd even say dozen times more than ensembles, percentage-wise seen.
> 
> It is as if a clear example was provided in C, so without classes,
> and then someone (an internet troll?) asking why don't use use C++ and
> classes.
> 
> So, please, be objective and stop flooding with arguments that aren't
> arguments.


Here is the argument: The purpose of [namespace ensemble] is to
provide a dynamically-configurable public interface for namespaces.
[clock] needs exactly that for the late loading of some of its
ensemble commands. [namespace ensemble] provides a facility to
accomplish exactly the functionality that you want to accomplish:
Bring a procedure into existence when the caller requests it. Here is
an implementation of late initialization of clock ensemble commands
using [namespace ensemble]:

      https://core.tcl-lang.org/tcl/info/ed50d4c0b3c7782e

This [namespace ensemble] implementation for [clock] is
straightforward, and uses namespaces and namespace ensembles as
intended.  The assumption of TIP 689 is that [namespace ensemble]
isn't good enough, and that therefore another facility should exist.
But why?  If the need for more dynamic namespace configuration was
foreseen, and [namespace ensemble] provided for that purpose, why add
yet another mechanism for doing the same thing?  So far, the only
rationale I've seen in the discussions for that is that "namespace
ensemble is too slow".  If that's true it could be addressed directly
instead of trying to work around it.

--
Yorick