From: SourceForge.net <no...@so...> - 2010-05-31 22:04:43
|
Bugs item #2965424, was opened at 2010-03-08 14:08 Message generated for change (Comment added) made by nijtmans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2965424&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 35. TclOO Package Group: development: 8.6b1.1 Status: Closed Resolution: Rejected Priority: 7 Private: No Submitted By: Jan Nijtmans (nijtmans) Assigned to: Donal K. Fellows (dkf) Summary: Tcl_OOInitStubs has no version parameter Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Jan Nijtmans (nijtmans) Date: 2010-06-01 00:04 Message: 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) ... ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-05-31 15:51 Message: Compile against 8.7 and load into 8.6? That's crazy talk! U.N.S.U.P.P.O.R.T.E.D! ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2010-05-31 13:45 Message: >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(). ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-05-31 12:38 Message: 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".) ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2010-05-31 10:07 Message: 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. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2010-05-30 19:15 Message: 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. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2010-03-08 14:56 Message: OK, here is a new patch, being more strict in requiring 'exact' version match. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2010-03-08 14:43 Message: In that, case, you can still use my patch, but set "exact' to 1. Then, at least, Tcl_OOInitStubs has the right signature. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-03-08 14:38 Message: I make no deep guarantees until version 1.0, which will correspond exactly with Tcl 8.6.0 ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2010-03-08 14:27 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2965424&group_id=10894 |