Abstracted from Tcl 9.0 WishList to make that page easier to read...

---

OO System. An OO system provided by the core should use Tcl_Objs, so that objects get deleted automatically when they go out of scope.

DKF - This is probably one of those things that is better left out of the core due to its contentious nature; there is not much agreement over what such an object system should look like, with the Itcl camp believing that because it is there, works and is used in quite a lot of code, it should be incorporated right now if not sooner, and the other camps asking if this is really all that good an idea (there are a lot of other extensions about, and one thing nobody wants is to force the use of a lot of different incompatible OO extensions in the same application!) Myself, I reckon that packaging Itcl in with the Tcl SDK but not integrating it with the core will be just fine, soothing a lot of ruffled feathers on all sides. Plus there's the whole question of the impact of the Feather and Namespace Regularisation work.

(I suspect that Tcl_Objs are being massively, and wilfully, misused. Their lifetimes are such that it is not generally useful to represent them as conventional objects; thinking of them as a way to cache converted representations is much more appropriate, and will not get anyone into trouble with vanishing values. The Obj bit seems to be utterly misleading to some people though, and they seem to feel that anything with those three letters in ought to behave according to their own particular prejudices, moaning when this is not the case. It is a deep shame IMHO that Tcl_Value was already taken with the math function code as that would have been a name more appropriate for the actual functionality of Tcl_Obj instances...)

</RANT>

Volker - I meant my statement that in case an object system gets incorporated in the core, those objects should be not just handles. I'm certainly aware of the fact that Tcl_Obj per se has not much to do with OOP, but I think they can be used to hold a struct with a couple of function pointers and some data fields.

DKF - xref to TCOM and TclMico here?

---

This discussion popped up in MicroTcl for Tcl9 but it really belongs here:

RWT - I have occasionally pondered the potential benefits of re-architecting the Tcl interpreter using an object oriented decomposition, and writing a new implementation in C++. If, for example, Tcl_Obj's stringRep was implemented as a C++ class, you could have both ASCII and Unicode versions which would be interchangable at compile time (or even run time). I could also imagine using C++'s polymorphism to implement interpreters with and without bytecodes. It seems to me that it might be a good way to modularize the core. I'm just not sure what a good O-O decomposition of a Tcl interpreter would be.

PSE - Well, I can't see why you would even call it Tcl except to invite disaster on Tcl as the teething pains of the C++ reimplementation drives new users away. I'm not sure that programming languages are appropriate targets for object model design. Note that Ruby, which is a beautifully designed OO language, is implemented in C. I would of course chuck all my opinions if confronted by anyone who had actually designed a general purpose language.

JCW - When I coded my TinyTcl [1] in C++ from scratch, I shared RWT's general conviction that C++ would dramatically improve/simplify/modernize such a new scripting core. Nowadays, I avoid C++ ... not because of the language, but because of deployment hassles. It turns out that when coding at such a low level, C++ does not add as much as when it is used in more abstract ways in higher-level tasks. All main scripting languages use C. Perl's "Topaz" was abandoned. Even newcomers such as Lua use C. My current position is that much of a scripting language should be scripted (though evidently not everything). There is no reason why a bytecode compiler has to start out in C, or why Tk's text widget has to be a huge chunk of C (a B-tree, totally tied in, and special purpose, what a waste!). The way to go is to build high-level, and then use machine code sparingly. Preferably as drop-in replacements ("performance plug architecture"). Much easier to code, much easier to test, with optional coding in C or whatever else makes sense. The "Squeak" (Smalltalk dialect) people got it right [2].

DKF: C++ tends to be a total PITA to deploy on Unix, especially for dynamic loadable shared libraries. The link process is often subject to what might best be called Voodoo, and C++ tends to set up loads of exit handlers, causing havoc when you try to unload a shared lib. C, for all its many faults, at least lets you control such stuff and it's much easier (not easy mind you, just easier) to link.

LV These days, even C dynamic libraries (like my gcc linking woes in relationship to building tclkit) can be a pain to resolve. However, the C++ problems take the dynamic library situation a set farther because of name mangling, which for some (most? all?) C++ compiler creators seems to change from one version of the compiler to the next.

---