Forum OpenACS Development: Re: The future of OpenACS

19: Re: The future of OpenACS (response to 1)
Posted by Gustaf Neumann on

Gustaf, what would be helpful here would be an API Browser for classes which lets you search for something like "xowiki::FormPage new" and display you the new function wherever it is defined with the link to the file it is defined on (in this case I think it is ::Generic::CrItem new, but I might be wrong). Or, if this exists, and explanation for an XoTCL dummy like myself where to find it :-).
One can always as xotcl, where and how a certain method is looked up. In the particular case, ::xowiki::FormPage procsearch new tells, that new a method of ::xotcl::Class implemented in C.

Your request is certainly valid. I have put an updated object/class browser into cvs head, which show the class hierarchy for classes together with the provided methods. It flags as well built-in methods with aC


If you delete the first part of the sentence, you can make any conclusion you want.
That is not very constructive. Read my posting again, i address arguments for refactoring in general as well.

xoTcl is not an extension of Tcl. It is a new language. If it were an extension, then the authors would not complain about uplevel and upvar.
Why is XOTcl no extension? A strange argument. I have not complained about upvar/uplevel in general (Tcl has so far no other way of doing a call by reference), but about its widely use e.g. in the templating code where variables are set and read on various call stack frames. Have you every tried to figure out, why e.g. an ad-form does not find variables in an adp_eval or adp_include? My impression was: better not touch this code. This is bad from a development point of view. What i am arguing that in many such cases there are better ways to encapsulate state or behavior, especially when efficient objects are available.

i am not understanding your paragraph with the "single complaint", the deficit of Tcl, the ignorance, and "people think they are smart". Maybe, a forum is not the best place to discuss this.

I would argue that Tcl is very object oriented, maybe exclusively object oriented
Well, by which definition? There were a vast number of articles written in the 80s and 90s about classification schemes for object orientation and object based systems (e.g. Peter Wegner). Tcl does not fit these definitions (i am in no way arguing that tcl is a bad language). Certainly, object orientation can be achieved without object oriented languages, object oriented support can be built in practically all programm languages on the framework or application layer. What's wrong for providing language support for object oriented aspects to make it more consistent?

Also openacs extends the language Tcl by ad_procs, introducing non positional arguments. Tcl is an extension language, this makes it powerful.


I have been using XOWiki for the last couple of weeks as it looks like a perfect fit for an upcoming project but I find it hard work to figure out whats going on.
Learning XoTcl or oo by studying a full-featured system like xowiki is as complex as learning Tcl from OpenACS. The xowiki documentation and FAQ are growing, but it is always hard to provide documentation for the right target group. Some people want an OO introduction, others are interested in the interaction with aolserver, others are need enduser documentation, or "Inside XoWiki". Feel free to ask question in the forums or send emails to me, i am always trying to be helpful. Gradually, the documentation improves, but it is slowed down by the innovation process within xotcl-core and xowiki.


Rewriting in XoTCL does not make any sense to me either.
Rewriting openacs code exactly like it is just for the sake of rewriting it does not make much sense for me either. Nobody argues for this. I have rewritten some code of openacs a couple of functions in the past. This task is a lot of work, mentally disturbing (some "objects" have a complex, grown behavior), the outcoming code is not a text-book example how object oriented code should be written. I am not arguing that someone should rewrite the code, but i am pointing to the benefits of the parts i have done in the past.

But I would not go and rewrite e.g. Forums in XoTCL unless there is a compelling reason to do so (read: customer requirement).
Haven't you asked for an XoWiki widget for forms? Wouldn't it be nice to have tags, categories, web 2.0 gadgets, social networking ... in forums as well? No, i am not volunteering in rewriting forums, but i want to point out that orthogonality and object oriented reuse makes sense for many openacs packages from an end user point of view as well.

Posted by Malte Sussdorff on
Haven't you asked for an XoWiki widget for forms? Wouldn't it be nice to have tags, categories, web 2.0 gadgets, social networking ... in forums as well?

Yes, I have asked for it and I would love to have it working in (primarily) project manager. Yet I would not go down the road and rewrite project manager in XoWIKI Forms or derive a class from an XoWIKI Page, because that does not make much sense to me (or am I mistaken here).

Therefore we would have to see how much of the functions you mention (which are all great) can be put into the Generic::CrItem class, or how much sense it makes to derive from XoWIKI based Classes for applications like contacts and project manager.

On a related note, if I were having a customer asking me for an implementation of forums which has all these things, I would probably base that off XoWIKI Page class and write a derived xowiki-forums package. But yet noone has asked me about that :-). I briefly thought about doing this in XoWIKI Forms but realized I would have to do a lot of construction, so I dropped this purely theoretical experiment.