Forum OpenACS Development: Re: XOTcl

11: Re: XOTcl (response to 10)

Posted by Mark Aufflick on 10/09/04 08:45 AM

I hadn't particularly investigated XOTcl - there are after all a number of object extensions to Tcl, none of which have set the world on fire.

At the moment, nearly all my client work has been developing Object Oriented Perl - some systems over 50,000 lines of code. I have to say that after that, going back to Tcl REALLY HURTS.

XOTcl gets a way towards providing better software engineering options. Given that one of my biggest gripes with Tcl is the lack of advanced data structures and the necessity for upvar's, XOTcl would allow me to design object libraries to be data structures for me. While not nearly as cool as Perl, if we could implement, for example, the entire gang of four set of objects & methods then OpenACS will be able to present itself as a far more serious and mature development environment.

Any comments or flames?

12: Re: XOTcl (response to 11)

Posted by Ola Hansson on 10/09/04 12:07 PM

Mark,

Could you elaborate on why going back to Tcl, after having used Perl, really hurts? Is it the object orientation versus procedural style, or something else?

As for "upvar" ... it isn't much worse than pointers in "C", is it? And I bet that you use pointers all the time when you're doing stuff with C.

So "object orientation" is far more mature than procedural now? That's funny, I would have thought it was the other way around.

Having said that, I think there's no doubt that OOP almost always provides a better way to write large programs than procedural programming does. But I am questioning if it is all that constructive to at this stage - given the established and well-proven structure OpenACS has today - introduce a new obstacle towards learning how existing packages work and how to develop new ones.

Putting an example package in contrib, that folks can look at for inspiration if they want to write custom code in OO style, is one thing (Herr Neumann, please do!) ... It is another thing to endorse XOTcl and divert scarse OACS developper resources to rewriting existing packages. That would have to be a fork of this toolkit, IMHO.