Hi all,
being a Tcl hacker and strongly engaged in the OO community sometimes makes me were two different hats ... surely, as a developer of XOTcl, I would love to see XOTcl in the core one day. I agree with Jeff's reasons given below, but what worries me more these days with regard to the future of Tcl, is that we are arguing whether to have OO in the core or not in a time when the OO community argues how to best support aspect-oriented programming and the likes. Three years ago I could tell the Java guys: "I use Tcl because in this language we can do things you cannot do" ... Today, with tools like AspectJ, Javassist, BCEL, and Eclipse around this is much harder to argue. Taking a look at modern middleware like IONA Artix + ART, at server-side component container architecture like JBoss, or at program development environments like AspectJ / Eclipse you can see that virtually every "en vogue" OO development has build or currently builds AOP abstractions into their systems. I have the fear that once we have some OO in the core, we are getting the same discussion for AOP abstractions as we have it now for (correct me if I'm wrong) at least 10 years for OO... my major point in favour for XOTcl is that it already provides AOP abstractions with its message interceptors in a rugged and efficient way ... and in Tcl's programming style.
just my 2 cents ...
Uwe
Jeff Hobbs wrote:
In fact, I'd be pleased to see Snit in the core - I really like the delegation model and I intend to start using Snit more in the future.
I'm not sold on snit, although we do use it. I want to have the opportunity to look into xotcl more in actual use. It has had a lot more large applications built with it, and has been "harder hit" (at least that's my impression).
Why? Because it is similar to snit, similarly it is a "Tcl-friendly OO model", but already done in C, even to the point of performance tweaking. People like snit because the model is good, and they can drop it in anywhere because it is pure Tcl.
However, a true core OO should be done in C. xotcl is that already. Sure, you can code parts of snit in C - but xotcl is already there *and tested*. It has active developers and interested users. It's even gone so far as to have an alpha "itcl compatability" mode that actually faster than the C coded itcl!
So why have I been slow in including it? Well, until v1.2 the build system was not TEA friendly. I strongly believe in extensions that behave as extensions, and it behaved as if xotcl was the world. Also, key to AS work in usage only, the TDK Compiler does not know how to precompile (hide/obfuscate) xotcl methods, so it wouldn't be too hard to go poking in our code (which we don't want ;) ).
Please note that this message crosses 3 mailing lists, so be conscious of who is on the to/cc for your replies.
Jeff
PS - Of course we still love Will's snit, which is why it actually made it into our code, but when we talk "core OO", there are different criteria to go by.
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl