Forum OpenACS Q&A: Would Openacs benefit if it had an object oriented scripting language?

I have to appreciate all the people behind this wonderful toolkit. It has been an amazing toolkit to learn and implement  useful websites. I have learnt a lot from this toolkit.

I have been developing in object oriented languages like C++ , Java and I am mighty impressed by the modeling ability they provide though they have their own issues. Openacs with its thin client system does provide to a certain degree the oject orientedness like creating a new application is by deriving from the existing system and most objects have  plsql procedures like new , delete that act like constructors and destructors respectively.

But my experience tells me that while developing applications  one encounters a lot of situations where the presence of OOP constructs help in creating simple and readable code which has huge benefits in constructing , debugging and maintaining systems. Intuitive reusability ( like having a user class with all functions for finding the properties of the user) and enabling development of complex applications which need a lot of business logic can happen to a greater degree if we can have an object oriented scripting language instead of TCL.

Any thoughts?

Well, I'm the last person to discourage discussion on any topic, but this one is imo basically settled in 2001 already (and at various occasions after that point in time).

See (among others):

Short summary: it has been giving some thought and the general outcome was basically "not worth the effort".

As the number of available "public" tcl procs grow, it would be useful to classify them. Make it easier to find existing procs.

The api-doc is the ultimate dynamic version of that. However, it would be useful to have a list of commonly used procs, sorted by the type of information returned (0 or 1, a number, a string, a list), or the "class" of information processed.  Hmm.. Aren't classes represented in openacs by package abbreviation? ec_ for ecommerce ad_ for kernel etc?

Maybe the api-doc could include a sort by frequency used in openacs code, to help find popular solutions and standardize coding practices. The statics could be built and stored in a table, updated with each significant version number.


I imagine all of the programmers working on OpenACS realize the benefits and drawbacks of object-oriented programming.

Me, I like OOP, but I'm not tied to it. I grew up in the procedural world of C, and I view OOP as a tool that has good and bad applications.

OpneACS started procedurally, and grew procedurally. There's no point (and not enough resources) in rewriting the hundreds of thousands of lines of code just so it can be OOP. Procedural works just fine, even though it also has its drawbacks.

It'd be interesting to see if one could use one of the Tcl OO extensions like XOTcl to write new OpenACS packages though, or even PyWX. I and a friend of mine recently looked at reviving PyWX (Python for AOLserver) and he almost got it to compile.


To my knowledge the university of vienna is using XOTcl for part of their custom code for .LRN. But I guess it really depends what you need this for.

If a new package would require the use of TCL LIB, we'd just add tcllib to the installation instructions, same can happen with XOTcl or other extensions that are loadable for OpenACS, so I don't think the community limits itself to just use TCL, but does not see much need for using something else (at the moment).

Actually, I do think we should think about supporting tcllib more, make use of it and get a decent API browser for the installed TCL commands.

These are very valuable additions to the api-doc and I hope someone has the time and courage to put them into being. I specifically like the implication of seeing best practises at a glance due to the times a certain function has been used.

Though I guess, we'd see how many deprecated functions are still in use :)....

hey Malte,
support for tcllib is indeed important, probaly add a search on the api-doc for commands, liking to


Harish, I'm no OO expert myself, but to the best of my knowledge, smart OO afficionados tend to consider Java and C++ to be fairly poor as object oriented languages go. Counter examples of powerfully object oriented languges might be Smalltalk, the Common Lisp Object System, XOTcl, or Python.

Malte, can you tell us more about how Vienna is using XOTcl, what they found it particularly good or bad for in the OpenACS context, etc.?

Lisp hacker Jonathan Rees (creator of T and Scheme 48) also have some interesting anti-OO thoughts. His take seems to jive with the OO criticisms from Date and the other relational model folks, note - especially that "OO is not well defined." Which doesn't mean that it isn't useful, of course.

Well, that's maybe off topic from what we were discussing here, but close enough and interesting enough that I wanted the excuse to post the link. :)

Roberto, speaking theoretically, if you could wave your magic wand and transform OpenACS from procedural style Tcl code to something OO, but otherwise very similar (XOTcl, perhaps), would the result be better or worse? Why or why not? I don't really know the answer to that myself, as I haven't done any real OOP work.

The question is more of "what if we had object oriented constructs?". I do appreciate the amount of effort that would have to be put in. I am also not particular about  C++ or Java. Procedural approaches is a simple and no -nonsense kind of way of programming and it makes life much easier when we develop small applications. As I see it Openacs has a lot of business logic sitting in the db ( which can only be written in the db's native language) and we create tcl wrappers to glue it with our webserver and remaining logic. It makes a lot of sense that we use a light weight , threadable scripting language like TCL to do such minimalist work.
From my limited programming experience I see the following issues:
1) Learning 2 different languages adds to the learning curve
2) Changes in the business logic can be tricky if it onvolves changing stuff at the db level.
3) Reusability is not obvious ( may be its more to do with engineering standards but a more obvious system helps)
4) Integrating applications (verticals) are difficult to implement
5) Implementing complex business logic

Would having object oriented constructs like classes and scoping improve these.

i must admit as a marketeer/sales engineer, it's often easier to say "we do OO". being able to plug in something like XOtcl would certainly be a boost.

i also assume that being able to use XOtcl in the context of the CR (which is nominally OO as well) might be a win.

at the same time... what the hell - is it that big of a deal? what we have in AOLserver is a kind of OO by default - nice APIs that save us from the horros of OR mapping. there may be some cleaning up of APIs and so forth that would improve the elegance of the engineering, but is that an issue with the language choice?

as someone said to me, OO is really just a set of ideas that good programmers use by default. the efforts the community has been focusing on for about two or three years now is defining and codifying those standards in various manners.

so i think the question that should be asked is less about whether we need OO (which XOtcl can offer if need be) and more about working on documentation and improving APIs.

switching languages/paradigms would just make the whole game more of a mess.

is that why you've not piped up, Don? :)


I guess I'll be the heretic here.  It's true OO has a lot of fans but in my experience it's equally likely to make your life worse.

It's easy to get hooked on inheritance, but inheritance can become incredibly brittle when you go beyond a level or two of subclassing.

It also increases the documentation burden, because the application logic tends to be implicit in your choice of class hierarchies and responsibilities.  So you're going to be writing a lot of ER diagrams in addition to api-docs.

We get a hint of these problems in the OpenACS's somewhat-OOpy permissions system.  For example, it's not uncommon to run into subtle, hard to debug side effects resulting from small but significant changes to objects that have numerous descendants in various parts of the permission hierachy.  I've personally worked on a couple of problems like this.  Here's a writeup of one of them:

So these days I'm not too big on OOP, at least not for marketing reasons.  I think it's great for GUI apps, and at least won't make your life worse if used expertly, but by and large isn't such a great fit on the server side.