Forum OpenACS Q&A: Would Openacs benefit if it had an object oriented scripting language?
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.
See (among others): https://openacs.org/forums/message-view?message_id=17737
Short summary: it has been giving some thought and the general outcome was basically "not worth the effort".
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.
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.
Though I guess, we'd see how many deprecated functions are still in use :)....
support for tcllib is indeed important, probaly add a search on the api-doc for commands, liking to http://tcllib.sourceforge.net/doc/category-index.html
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.?
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.
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 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? :)
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.