The software engineering community has well adopted design patterns as *the* concept for best practices in the field and xotcl provides tcl constructs for implementing design patterns.
This is not true. Certain segments of the software engineering community have adopted design patterns as *the* concept for best practices, large segments have not.
Unless, of course, you don't consider those working on tools like the Linux kernel, PostgreSQL, Apache, and AOLserver software engineers.
Design patterns may turn out to be yet another passing fad among a fashionable set of software engineers and academics.
Regardless, we've adopted an abandoned piece of software that was not written with this paradigm in mind. Is this a great design or a design that couldn't be improved? In my opinion, no it's not and yes it could be. However it's a servicable design, much more so than the supposedly more pure and holy and object-oriented design of its successor, ACS Java implemented by True Believers in the design patterns paradigm.
You are right that OpenACS 4 already includes too many hacks, different code approaches which solve the same problem, no standard way of using the object-oriented datamodel, etc. All things we've inherited. If you read my posts to the forums - and I've posted a time or two, as I'm sure you're aware - you'll see a couple of common threads that winds through all my thinking.
The first is that, despite its flaws, I think the current design is servicable and I'm not personally interested in leading or being involved with a project to rewrite it. I've encouraged those who might - you, for instance - to consider starting up an alternative project and have suggested that we might even want to host it here at openacs.org as a research project that may or may not bear fruit in the future.
A second thread is that I constantly argue that we work to rationalize the use of the code base and datamodel and that we put a stop to various packages implementing ad hoc solutions that duplicate those that already exist and are servicable. A recent example is that I tossed out Ben's reimplementation of non-versionable objects that are used to provided URL content in file-storage. The content repository already had a perfectly servicable external link type that wasn't completely implemented by aD before ACS Tcl was dropped. I completed the implementation and got rid of Ben's parallel code. Another example is the growing consensus in the community behind the use of the ATS form builder to provide a consistent look and feel for forms, and a consistent coding paradigm to implement form handling pages. We've got a long ways to go, but surely adopting one standard way to build and handle forms is better than the situtation we inherited from aD, where ad hoc form handling along with the form builder appeared in various packages.
I could go on and on but certainly one of my major themes, perhaps the major theme of whatever level of direction I provide for the project, has been that we should scrap the use of redundant and usually inadequate approaches to various coding problems and adopt a single approach for use throughout the toolkit.
I describe your approach as "anarchist" because, rather than following that trend, you've written a package that uses a custom templating system rather than the perfectly servicable (though clearly imperfect) existing templating system. This automatically makes your new package uninteresting in the context of the OpenACS 4 toolkit.
As a research project, or a demonstration of how a rewrite or reimplementation of the toolkit might be an improvement over the existing system, it may very well be interesting indeed, but code written in a different programming language using a parallel templating system rather that the existing templating system we've adopted as an OpenACS 4 standard will not become part of the OpenACS 4 toolkit. Not as long as I'm in a leadership position, that is. On the other hand, a clean break with the past wouldn't bother me at all, as was done with ACS 4 vs. ACS 3, if there are folks that would like to do that rather than flog OpenACS 4 into shape.
BTW, xotcl used properly as an object-oriented extension of Tcl leads to code different enough than the Tcl code folks are used to reading that for all practical purposes it is a different language. In the same sense that C++ is a different language than C even though it's just an extension to C. I realize that quantitatively the difference between xotcl and tcl proper is much less than C++ vs. C - I am a language implementor by trade, after all - but qualitatively xotcl was developed to support a particular programming paradigm.
