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.
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.
apw 2007-09-10 I have added an experimental version of 3 new commands (with sub commands) to itcl:
they have the same functionality as the corresponding commands described in TIP #257 i.e.: ::oo::define objectOrClass filter filterName ? ... ? etc.
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.
apw I am in close contact to the TCT members, and they told me about the places where there are some workarounds in Tcl core to make Itcl still running. I have addressed these problems and have now built a version which avoids these critical places in Tcl core. So the "I have heard" is already mostly solved. For additional interfaces to make Itcl more independent of Tcl core I am in contact with miguel and dkf and we are on the way to get a good solution some time in the (I hope) not so far future. So everything with itcl-ng is running well at the moment.