No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Collections
From: <MichaelL_at_frogware.com>
Date: Mon, 12 May 2003 13:30:39 -0400
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_at_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
Date: Mon, 12 May 2003 13:30:39 -0400
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_at_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