Tcl Source Code

    Tcl_Object 
    Tcl_NewObjectInstance(interp, class, name, nsName, objc, objv, skip) 

...

const char *nsName (in)
    The name of the namespace to create for the object's private use, or NULL if a new unused name is to be automatically selected. 

...

If the nsName value passed in names an existing namespace, T_NOI() does
not raise an error, nor does it use the named namespace.  It silently
falls back to behaving as if nsName==NULL was passed in, and generates
a new namespace.

This should at least be made more clear in the documentation.

Itcl 4 suffers from this.  See http://core.tcl.tk/itcl/tktview?name=f3a2e7407c

The workaround is here: https://core.tcl-lang.org/itcl/info/46272cca4dc657b3

The TTT sees this as solved. Reverting on 8.6 would also be possible but this patch is also ok.

Thanks for all, Harald

While I am not able to solve these issues quickly, I was able
to hack in a workaround in Itcl.  Review and comment would
be helpful.

I do not possess a strong knowledge of what other codebases
make use of the TclOO C API and might also be upset by this.
How can we find out?

"it's technically a public API change, but one that I think nobody will notice and care about."

I don't see how that can be said when Itcl's expectations were what
raised the question in the first place, and testing Itcl immediately
shows the breakage.

The issues here are difficult and beyond what I can solve quickly.
But shouldn't we at least keep this breaking change out of 8.6.15?
As is, the release candidate of Tcl 8.6.15 breaks the released Itcl 4.2.5
as well as the latest sources poised to become Itcl 4.2.6.

To be more concrete, here are two of the simple test failures
in the Itcl test suite:

==== fossil-9.0 d0126511d9 FAILED
==== Contents of test case:

    itcl::class N {}

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: can't create namespace "N": already existsITCL: cannot create Tcl_NewObjectInstance for class "::N"
    while executing
"itcl::class N {}"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $script"
---- errorCode: TCL OPERATION NAMESPACE CREATEEXISTING
---- Test cleanup failed:
class "N" not found in context "::"
---- errorInfo(cleanup): class "N" not found in context "::"
    while executing
"itcl::delete class N::B N"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $cleanup"
---- errorCode(cleanup): NONE
==== fossil-9.0 FAILED



==== fossil-9.1 d0126511d9 FAILED
==== Contents of test case:

    itcl::class N {}

---- Test setup failed:
class "N::B" already exists
---- errorInfo(setup): class "N::B" already exists
    while executing
"itcl::class N::B {}"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $setup"
---- errorCode(setup): NONE
---- Test cleanup failed:
class "N" not found in context "::"
---- errorInfo(cleanup): class "N" not found in context "::"
    while executing
"itcl::delete class N"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $cleanup"
---- errorCode(cleanup): NONE
==== fossil-9.1 FAILED

These tests were created when the issue in this ticket was
first addressed back in 2015 to detect if it would ever come back.
Should not really be a surprise this change makes them fail.

I am sorry that my assessment is not timely, but this change
broke the trunk of Itcl. It creates multiple test suite
failures.

Since this change was put into both the 8.6 and 9.0 branches,
the issue is blocking releases until it is decided which must
change and how.

None of our auto-testing systems cover Itcl?  Can that be right?

Donal, thank you for the great fix.

The decision to merge or not should be done.

Please post your opinion here.

I will merge in one week (31th of May) if no strong objections. I will also write a message on the core list.

Thank you and take care, Harald

Documented that the namespace should not already exist.

My (mild) preference is to leave this unresolved until I
can get back to and complete my experiments in Itcl 4 dealing
with the implications of this interface restriction.

dkf is welcome to comment on any necessities behind it.

ping ... status?

It appears that the TclNRNewObjectInstance function duplicates some (or all?)
of the code involved as well.