Zoran Vasiljevic wrote:
Am 26.09.2005 um 19:40 schrieb Jeff Hobbs:
TIP #257: Object Orientation for Tcl http://www.tcl.tk/cgi-bin/tct/tip/257First of all, this is a step in the right direction which should have been done *years* ago already. Many thanks to the creators of the TIP for their courage to open this can of worms again. I believe there will be many kudos *and* resistance from the user base of (all) OO systems luring arround in the Tcl community.
We are using XOTcl in a commercial MT-app already 5 years and, personally, I doubt that a (new) piece of software can reach the stability, performance and functionality of XOTcl in a reasonable time. Hey, since the proposal is based on XOTcl, why just not adopt XOTcl codebase? This would save lots of time and effort. I do understand that from syntactical point of view, some XOTcl pieces may/should be ommited or changed to satisfy C#/C++/Java folks, allright, but I believe this is easier done by taking the XOTCl codebase and tweak it, rather to write all from scratch.
to let the XOTcl folks know: this was just what I responded to the Tcl core folks when I saw the second version of the TIP. Some of the changes proposed are good ideas, others are just personal taste or syntactic sugar, while still others seem to be problematic from a conceptual point of view. I find it hard to discuss all these issues in one big step; to have a plan to do this is good -- and moving away from XOTcl's model is not a problem for me -- but doing all at once, all from scratch, without much experimentation will IMHO mean a long, long time until we have a stable OO language in the core, which will likely have only a mediocre object model design.
Im my opinion, the first step must be to make the Tcl core ready for OO, meaning to open the C implementation of Tcl namespaces with extension points for dispatching of subcommands (which will be methods in OO languages) and opening up the callstack for extensions. These are important conceptual considerations, which are not easily done, because a number of overlapping concepts need integration: objects, classes, namespaces, ensembles; and: callstack of Tcl, callstack of any OO extension, uplevel/upvar. Please note, this cannot be done without designing a dispatch model for the language (i.e. in XOTcl's model: the dispatcher bound to the object commands, self, and next), and the creation schemes/destruction orders of object/classes/namespaces must be aligned.
My point is: get these fundamentals of the object system right first, because once an official OO core extension is rolled out to the Tcl community, it might be too late to do fundamental changes. It seems natural to me, to use the existing XOTcl code base as a basis for experimenation and testing and do these changes to the core first, and once this is done, think about the details of the OO model. BTW, the issues mentioned above are the points where the new object system would benefit most from the integration with the core; due to missing extension points these are the points that are more cumbersome in XOTcl's C implementation. But at the moment, this is not addressed. In the TIP it is unclear: will these fundamentals work similar as in XOTcl or not? How is the plan to merge them with the core? At the moment, it is seems as though only a pure extension is planned, which is not a good idea in my point of view. Why not benefit from the core integration?
To answer two objections to my earlier post:
1) Backwards compatibility is not an issue here, because we're talking about pure extensions to the known Tcl concepts. Pure Tcl programs will run without changes. 2) I'm not at all talking about turning Tcl into an OO-only language. My point is that each namespace should have the capability to be lazy and automatically be turned into an object, so that there are no frictions to use objects and namespaces together. At the moment, each XOTcl object lazily aquires a namespace when it needs one, there's no reason, why this cannot be done the other way round, i.e. the namespace aquires its object command, when requested, or the namespace command is bound to a stub which intializes the object structure at first use.
Cheers,
Uwe