From Newsgroup: comp.lang.tcl

There are quite a few commands provided in Tcllib that create _global_ commands.
Here are just 3 examples (there are others):

::struct::disjointset disjointsetName
Creates a new disjoint set object with an associated global Tcl command

::struct::graph ?graphName? ?=|:=|as|deserialize source?
The command creates a new graph object with an associated global Tcl command

::struct::tree ?treeName? ?=|:=|as|deserialize source?
The command creates a new tree object with an associated global Tcl command

Given that TclOO is a standard part of Tcl and that since Tcl 9 offers
very comprehensive OO support, ought the Tcllib commands that create global
Tcl command be deprecated in favour of new commands (to be added) which
create actual objects?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Mark,

While I understand the motivation (and temptation), I think it would be
ill advised given the volume of code in tcllib and the effort required
for implementation (including updating the test scripts). And that's
before considering the impact on tcllib users.

I feel time would be better spent elsewhere. Just an opinion.

Of course, above only applies to existing modules, not new ones.

/Ashok

On 7/30/2026 3:33 PM, Mark Summerfield wrote:

Given that TclOO is a standard part of Tcl and that since Tcl 9 offers
very comprehensive OO support, ought the Tcllib commands that create global Tcl command be deprecated in favour of new commands (to be added) which create actual objects?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 7/30/26 6:03 AM, Mark Summerfield wrote:

There are quite a few commands provided in Tcllib that create _global_ commands.
Here are just 3 examples (there are others):

::struct::disjointset disjointsetName
Creates a new disjoint set object with an associated global Tcl command

::struct::graph ?graphName? ?=|:=|as|deserialize source?
The command creates a new graph object with an associated global Tcl command

::struct::tree ?treeName? ?=|:=|as|deserialize source?
The command creates a new tree object with an associated global Tcl command

Given that TclOO is a standard part of Tcl and that since Tcl 9 offers
very comprehensive OO support, ought the Tcllib commands that create global Tcl command be deprecated in favour of new commands (to be added) which create actual objects?

For those of us who prefer a procedural programming model, this would
not be a welcome suggestion. If module authors want to update their own
code to support this paradigm, of course they can do so. But Tcl is not
Ruby ("everything is an object") and I would not want it to become Ruby.

- Kevin
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Isn't it a false good idea to name those "object" when they are in fact "namespace" ?

Also some of them are nicely imbricated for example : matrix, report, csv. You will
need a huge workforce to achieve this, unless you use AI, a lot of money
and manage licenses of different authors.

You will probably have to create a fork of Tcllib with only a few modules as a start.

Olivier.



Mark Summerfield <[email protected]> posted:

There are quite a few commands provided in Tcllib that create _global_ commands.
Here are just 3 examples (there are others):

::struct::disjointset disjointsetName
Creates a new disjoint set object with an associated global Tcl command

::struct::graph ?graphName? ?=|:=|as|deserialize source?
The command creates a new graph object with an associated global Tcl command

::struct::tree ?treeName? ?=|:=|as|deserialize source?
The command creates a new tree object with an associated global Tcl command

Given that TclOO is a standard part of Tcl and that since Tcl 9 offers
very comprehensive OO support, ought the Tcllib commands that create global Tcl command be deprecated in favour of new commands (to be added) which create actual objects?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Olivier <[email protected]d> wrote:

Mark Summerfield <[email protected]> posted:

There are quite a few commands provided in Tcllib that create _global_ commands.
Here are just 3 examples (there are others):

::struct::disjointset disjointsetName
Creates a new disjoint set object with an associated global Tcl command

::struct::graph ?graphName? ?=|:=|as|deserialize source?
The command creates a new graph object with an associated global Tcl command >>
::struct::tree ?treeName? ?=|:=|as|deserialize source?
The command creates a new tree object with an associated global Tcl command >>
Given that TclOO is a standard part of Tcl and that since Tcl 9 offers
very comprehensive OO support, ought the Tcllib commands that create global >> Tcl command be deprecated in favour of new commands (to be added) which
create actual objects?

Isn't it a false good idea to name those "object" when they are in fact "namespace" ?

Also some of them are nicely imbricated for example : matrix, report, csv. You will
need a huge workforce to achieve this, unless you use AI, a lot of money
and manage licenses of different authors.

You will probably have to create a fork of Tcllib with only a few modules as a start.

Olivier.

The namespace ensembles created by these commands act like (and have
some of the qualities of) objects. They call their internal procedures
via "method names" (while not actually calling them 'methods') and they provide a "package of isolated [1] data (namespace variables) and methods
(the procedures) to operate on that data".

They very much fit the "if it walks like a duck, and it quacks like a
duck, then it might very well be a duck" mindset. So calling them
'objects' is not too far from reality.


[1] as isolated as anything can be in Tcl given its strong
introspection abilities.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


Rich <[email protected]d> posted:

They very much fit the "if it walks like a duck, and it quacks like a
duck, then it might very well be a duck" mindset. So calling them
'objects' is not too far from reality.

What I had in mind is that naming "namespace" as "object" can lead one to believe that Mark's idea seems feasible. But beyond this concept, unless to have
an army of gifted programmers, it will need a lot of work and time to achieve this
without breaking how Tcllib was constructed during years.

PS : In ducks world, The Ugly Duckling story has taught us that what we believe can be far from reality ;-) !
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Olivier <[email protected]d> wrote:

Rich <[email protected]d> posted:

They very much fit the "if it walks like a duck, and it quacks like
a duck, then it might very well be a duck" mindset. So calling them
'objects' is not too far from reality.

What I had in mind is that naming "namespace" as "object" can lead
one to believe that Mark's idea seems feasible. But beyond this
concept, unless to have an army of gifted programmers, it will need a
lot of work and time to achieve this without breaking how Tcllib was constructed during years.

Fully agreed. The work involved will be huge. And as Tcl's all
volunteers anyway, *someone* has to step up to put in the work.
Without that, it won't happen.
--- Synchronet 3.22a-Linux NewsLink 1.2