Tcl Source Code

Compare the following:
   Tcl_InitStubs(interp, "8.5", 0)
with
   Tcl_OOInitStubs(interp)

The version parameter of XX_InitStubs means the
lowest version supported by this extension. However,
in TclOO this value is already filled in being TCLOO_VERSION,
which is the "compiled-against" version.

The problem with this is, when someone compiles an extension
using TCLOO_VERSION = "0.6.3", but runs it with Tcl 8.6b1,
the XXInitStubs call will  fail, even though it should run perfectly.

There is a difference between the "lowest supported version",
and the "compiled against" version. It should be possible to
compile a TclOO extesion against TclOO 0.6.3 and run it
using TclOO 0.6.2: As long as no 0.6.3-specific features are
used (and the extension developer is the only one knowing
this), everything should be fine.

More specific, I suggest to change:
#define Tcl_OOInitStubs(interp) \
Tcl_PkgRequire((interp),"TclOO",TCLOO_VERSION,0)
to
#define Tcl_OOInitStubs(interp, version) \
Tcl_PkgRequire((interp),"TclOO", version, 0)
Maybe we should even have an "exact'
parameter, just as the other *StubInit functions. 

This needs to be coordinated with Itcl and tdbc,
because it introduces a source incompatiblility!
Binary compatibility is not affected, except for
the "exact" parameter!

B.T.W: Tdbc_InitStubs has the same problem, but
Itcl_InitStubs is O.K.
B.T.W.: Personally, I don't mind very much about the
"exact' parameter, but I could imagine the desire
to keep it exactly the same as Tcl.

Depends on whether they've both got the same version of TclOO's ABI; the TclOO version is not required to be lock-stepped to Tcl's. The only thing I'll guarantee is that TclOO 1.0 will correspond to Tcl 8.6.0, when that happens, but 8.6.1 might still correspond to 1.0.

How about compiling against 8.6.1 and load into
8.6.0? Is that supported? (the way it is now, that
wouldn't work either) ...

allow_comments - 1

Compile against 8.7 and load into 8.6? That's crazy talk! U.N.S.U.P.P.O.R.T.E.D!

>Note that I'm being stricter about how I update the ....
Full agreement here!

>Because of this, there is no reason for people to select any API version....
The only reason there is, is someone compiling a TclOO extension
against Tcl 8.7 (including TclOO 1.1), which only uses
the TclOO 1.0 API, and then expecting it to run with Tcl 8.6
as well. That wouldn't work. If TclOO 1.1 is upwards compatible
with TclOO 1.0, there is no reason that would not work,
except from the explicit check in TclOO_InitStubs().

My position is clear. With TclOO I support using an extension compiled against one version of TclOO with later versions of TclOO. I also only support it if it is compiled with stub support; people building statically are unsupported (and there's certainly no ABI migration strategy there in any case). Because of this, there is no reason for people to select any API version other than the current (and with the "or later" option enabled) in the call to the *InitStubs call, so I removed the choice and made the API much simpler.

Note that I'm being stricter about how I update the TclOO API and ABI than even Tcl normally is. I'm pretty sure that I've got the structures well-designed enough to support that from the beginning. (The exception is if they work with TclOO's internal API, but in that case there's *no* version guarantee beyond "I won't break things gratuitously".)

Thanks for your reaction.

Where can I find more about this? Is it ever discussed
anywhere? (I happen to disagree, but I know that more
people in the TCT vary in opinion about this).

My view: Indeed, the package release version is different from
an ABI. But because Tcl promises to keep the ABI upwards
compatible in minor releases, there would never exist
different ABI versions for equal package versions. I
never saw an ABI version other than 0 anywhere.
So, yes, I would like to couple the ABI version to the
package version: Any ABI incompatible change should
lead to a new major package version. That's what
Tcl has done always, and extensions should do
the same.

For what it's worth, I believe the one-argument form XXX_InitStubs(interp); is to be preferred for all new stubs-supplying extensions.  The three-argument form XXX_InitStubs(interp, version, exact); is error-prone and incorrectly couples the package release version to the ABI version.

OK, here is a new patch, being more strict in requiring 'exact' version match.

File Added - 365822: 2965424-2.patch

In that, case, you can still use my patch, but set "exact' to 1. Then, at least,
Tcl_OOInitStubs has the right signature.

I make no deep guarantees until version 1.0, which will correspond exactly with Tcl 8.6.0

The proposed patch has the 'feature' that binary compatibility is
guaranteed, but source compatibility is affected. However,
TclOO extensions which are modified, immediately are
binary compatible with 'the right way'.

See the TODO in the patch.

File Added - 365821: 2965424.patch