Version 13 of itcl-ng

Updated 2007-09-10 11:20:15 by LV

Why do I build itcl-ng (itcl-Next Generation)?

About September 2006 I (apw) started to think about the future of incr tcl / Itcl. I had heard that there are a lot of problems in Tcl core because of Itcl. So I was thinking about a new version. The first idea was to build a Tcl only version. The story of that approach can be seen at tclOO missing features for Itcl.

After all I have started for the 4th time using original Itcl source code (because of performance problems with the other projects) and replacing all the dispatching and the code directly working in Tcl core areas with tclOO and a small layer which can perhaps in the future be integrated into Tcl core.

Goals, ideas etc.

  1. to make Itcl easier to maintain with respect to Tcl core (at the moment there are a lot of "hacks" in Tcl core only needed for Itcl)
  2. use tclOO as a dispatcher and to use in the future some of the features available there (filters, mixins)
  3. try to make Itcl an extension which is independent of Tcl core in that it uses only published Tcl_ interfaces (that means no use of tclInt.h)
  4. to make it in the long range faster then the old version and perhaps more attractive
  5. ....

Progress:

apw 2007-09-08 Today I have finished the implementation of the very first version of itcl-ng which is passing Itcl test suite with 0 failed test cases and 400 succeded ones. An almost up-to-date version is now at Sourceforge in the incr tcl repository [L1 ] with tag itcl-ng. Same is done for itk which is running about 98 of 100 tests successfull.

LV To which problems do you refer when you say that you had heard "[...]that there are a lot of problems in the Tcl core[...]"?

I can think of one possibility to which you might be referring. A TIP was approved to include itcl in the tcl core distribution. However, to move forward on this, someone who knew itcl internals sufficiently was needed to work on the changes that would be necessary to get the code integrated into the build process (and, likewise, to separate itcl from itk in its current distribution). As far as I am aware, no one ever stepped forward to work on that.

Otherwise, I would have to assume that itcl requires some internal functionality from the tcl core. If _that_ is the case, then while having a new OO extension built on tclOO is useful, to help the tcl core situation, one has to guarantee that people don't continue to use the old version. I suppose that the stubs interface could change in a way that the old version of itcl wouldn't work with a new version of Tcl. That would force the situation. It could also generate a lot of bad feelings, unless the change were critical.

Category Extension | Category Object Orientation