I am slowly starting the implementation of TIP 723 "timer".

The timer command should be an ensemble, to be extensible.
Or is this a stupid idea?
I thought, most core commands are ensembles. Is this true?
I don't find any reference to CreateEnsemble expect in the library/tclEnsemble.c file. How do I design a core command as ensemble ?

Thanks for any idea,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 22.08.2025 um 11:45 schrieb Schelte:

On 21/08/2025 18:19, Harald Oehlmann wrote:

I don't find any reference to CreateEnsemble expect in the library/
tclEnsemble.c file.

One of the references in library/tclEnsemble.c is in the function TclMakeEnsemble(). Tthat is the function that most core ensembles use.

Schelte.

Great pointer, thanks, I appreciate.
Yes, binary, string, namespace, they are all there.

That is great, thank you !

Take care,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/08/2025 18:19, Harald Oehlmann wrote:

I don't find any reference to CreateEnsemble expect in the library/ tclEnsemble.c file.

One of the references in library/tclEnsemble.c is in the function TclMakeEnsemble(). Tthat is the function that most core ensembles use.


Schelte.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Just to clarify, I was not referring to the command syntax but only to
the implementation as ensembles that can be extended. Implementing
commands with subcommands via good old Tcl_GetIndexFromObj is often
simpler and faster. What you lose is user-extensibility which imo is not
always desirable. Still, I suppose the fact most core commands are
implemented that way now would imply I am in the minority in that opinion.

/Ashok

On 8/30/2025 12:02 PM, Ashok wrote:

While I am neutral on implementation as ensembles, I will point out that extending core command ensembles with user / package defined ones has
the potential for conflicts for the same reasons as adding commands to
the global or tcl namespaces.

/Ashok

On 8/22/2025 3:39 PM, Harald Oehlmann wrote:

Am 22.08.2025 um 11:45 schrieb Schelte:

On 21/08/2025 18:19, Harald Oehlmann wrote:

I don't find any reference to CreateEnsemble expect in the library/
tclEnsemble.c file.

One of the references in library/tclEnsemble.c is in the function
TclMakeEnsemble(). Tthat is the function that most core ensembles use.


Schelte.

Great pointer, thanks, I appreciate.
Yes, binary, string, namespace, they are all there.

That is great, thank you !

Take care,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

While I am neutral on implementation as ensembles, I will point out that extending core command ensembles with user / package defined ones has
the potential for conflicts for the same reasons as adding commands to
the global or tcl namespaces.

/Ashok

On 8/22/2025 3:39 PM, Harald Oehlmann wrote:

Am 22.08.2025 um 11:45 schrieb Schelte:

On 21/08/2025 18:19, Harald Oehlmann wrote:

I don't find any reference to CreateEnsemble expect in the library/
tclEnsemble.c file.

One of the references in library/tclEnsemble.c is in the function
TclMakeEnsemble(). Tthat is the function that most core ensembles use.


Schelte.

Great pointer, thanks, I appreciate.
Yes, binary, string, namespace, they are all there.

That is great, thank you !

Take care,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ashok,
I thank you for the comment.
I only remember a post by Don Porter, that nowdays, all core commands
are ensembles. That is the only reason, why I tried an ensemble
implementation. I personally never used ensembles in a consious manner.

Thanks for all,
Harald

Am 30.08.2025 um 08:40 schrieb Ashok:

Just to clarify, I was not referring to the command syntax but only to
the implementation as ensembles that can be extended. Implementing
commands with subcommands via good old Tcl_GetIndexFromObj is often
simpler and faster. What you lose is user-extensibility which imo is not always desirable. Still, I suppose the fact most core commands are implemented that way now would imply I am in the minority in that opinion.

/Ashok

On 8/30/2025 12:02 PM, Ashok wrote:

While I am neutral on implementation as ensembles, I will point out
that extending core command ensembles with user / package defined ones
has the potential for conflicts for the same reasons as adding
commands to the global or tcl namespaces.

/Ashok

On 8/22/2025 3:39 PM, Harald Oehlmann wrote:

Am 22.08.2025 um 11:45 schrieb Schelte:

On 21/08/2025 18:19, Harald Oehlmann wrote:

I don't find any reference to CreateEnsemble expect in the library/
tclEnsemble.c file.

One of the references in library/tclEnsemble.c is in the function
TclMakeEnsemble(). Tthat is the function that most core ensembles use. >>>>

Schelte.

Great pointer, thanks, I appreciate.
Yes, binary, string, namespace, they are all there.

That is great, thank you !

Take care,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <108u6dp$2et73$[email protected]>,
Ashok <[email protected]> wrote:

Just to clarify, I was not referring to the command syntax but only to
the implementation as ensembles that can be extended. Implementing
commands with subcommands via good old Tcl_GetIndexFromObj is often
simpler and faster. What you lose is user-extensibility which imo is not >always desirable. Still, I suppose the fact most core commands are >implemented that way now would imply I am in the minority in that opinion.

Just out of curiosity, when you say "los[ing] user-extensibility is not
always desirable", do you mean that losing it is sometimes desirable and sometimes not *or* do you mean that user-extensibility itself is not always desirable?

--
After Using Gender Slur Against AOC, GOP Rep. Yoyo Won't Apologize 'For Loving God'.

That's so sweet...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)