I must admit that I was only thinking about elegance, and hadn't thought about memory and performance implications.
One option, I suppose, is to use a flyweight approach. In other words, pass the list in as a parameter to some function/object. This is roughly analogous to using the existing list commands in pure Tcl. The difference is simply that it would be possible to add a number of convenience functions in an XOTcl implementation. For example, Tcl doesn't have a simple "add only if it isn't there" command or a simple "copy list" command (you use lrange with specific arguments) or a simple "delete element" command (you use lreplace with specific arguments). Such an approach would only be a small improvement, but maybe it would be enough. It would certainly be easier than a full implementation of lightweigt objects. :-)
You do, however, hint that there may be plans for ongoing development. Are there specific plans, or just a general interest is evolving it "somehow"?
Gustaf Neumann neumann@wu-wien.ac.at wrote on 05/12/2003 12:39:44 PM:
On Monday 12 May 2003 17:36, Uwe Zdun wrote:
This corresponds to the idea of making filters etc themselves objects. I like this idea from a conceptual point of view. Implementation-wise it could be a larger undertaking ... the problem is that these "collections" manage different things at the C-code level (Tcl_Obj*s,
Cmds,
etc) in lists and hashtables and that some parts are not under control
of
XOTcl's C code (children are managed by Tcl in Namespaces). So really
a 2.0
issue :)
same opinon here; we had already some discussion some time ago about transforming e.g. methods into objects, etc. We did a big step in this direction when we implemented our "light-weight objects", which require namespaces etc on demand (please note, that lightweight is relative; see also http://media.wu-wien.ac.at/download/mem.log). But still, objects are costly in terms of time and memory.
I am pondering since a while about a simple thing: transforming xotcl parameters into objects. Conceptually, this is quite simple, but has disadvantages from benchmarks etc, whenmultiple objects are created on the fly, in situations where the users expects one class/object to be created. Maybe we are able to provide object facades, or to create these
interface
objects on demand, while keeping low-fat memory strucutures....... but
this
will take a few releases...
greetings -gustaf
-- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik WU-Wien, Augasse 2-6, 1090 Wien