[Xotcl] TIP #257: Object Orientation for Tcl

[Uwe Zdun]

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/257
>>
>
> First 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

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun at acm.org, uwe.zdun at wu-wien.ac.at