<blockquote>Randy O'Meara:
You say it's a package...as in OpenACS singleton service
</blockquote>
it uses 2 "nonstandard" c-based extensions
* thread 2.6
* xotcl
when these are installed, we have
* 2 (xotcl) files for .../modules/tcl/
(one high level interface for threads, one for
throtteling + statistics)
* 3 files or so for the presenting the statistics
in a first step i can put together a tar file + README,
it should not be hard to make an apm package out of this.
we have some statistics included that depend on our
e-learning packages (like exercises per minute), that
must be stripped off; i should be able to do this
over the weekend and make it available...
<blockquote> Ola Hansson:
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.
</blockquote>
This is certainly a very important concern.
an OO language can be used in various ways;
given the large corpus of existing code, moving
the core structure to OO is not realistic in
the near future and would most probably
lead to a different project (Neophytos did
something like this quite a while ago for a
site he is operating).
However, using OO to improve reusability and
fexibility of the tcl structures and functions
is worthwile. after all, xotcl is tcl with a
few more predefined commands, so it integrates
smoothly. e.g. xotcl can improve caching in
many ways.
-gustaf
