This is an item for the suggestion box.
XOTcl uses a number of collections: filters, mixins, children, etc. It may perhaps make sense to introduce a real collection class or abstraction, and implement those concepts directly *as* collections. Reading through a lot of XOTcl code--eg, xoRBAC--you can see that the same themes appear over and over again, such as checking to see if an object is already mixed in. Right now "append"--and only "append"--is built into the list of supplied Object methods (eg, "filterappend"). Rather than flooding Object with more and more collection management procs it might be better to expose the filter collection as an object that supports operations directly (like "append" and "contains" and "remove").
This is more like a 2.0 change--and presupposes that there will be a 2.0. :-)
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 :)
Uwe
On Monday 12 May 2003 16:47, MichaelL@frogware.com wrote:
This is an item for the suggestion box.
XOTcl uses a number of collections: filters, mixins, children, etc. It may perhaps make sense to introduce a real collection class or abstraction, and implement those concepts directly *as* collections. Reading through a lot of XOTcl code--eg, xoRBAC--you can see that the same themes appear over and over again, such as checking to see if an object is already mixed in. Right now "append"--and only "append"--is built into the list of supplied Object methods (eg, "filterappend"). Rather than flooding Object with more and more collection management procs it might be better to expose the filter collection as an object that supports operations directly (like "append" and "contains" and "remove").
This is more like a 2.0 change--and presupposes that there will be a 2.0.
:-)
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
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
-
Gustaf Neumann -
MichaelL＠frogware.com -
Uwe Zdun