No registered users in community xowiki
in last 10 minutes
in last 10 minutes
XOTcl/NX mailing list by object move?
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 18 Mar 2006 21:39:35 +0100
Scott Gargash schrieb:
>
> xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/18/2006 01:45:12 AM:
>
> >
> > On 18 Mar 2006, at 02:48, Gustaf Neumann wrote:
> >
> > > so, now we can test the aliased content. it behaves in many respects
> > > the same, but when it comes to refer to "self" or to namespaces
> > > one would notice a different behavior:
> >
> > Could this kind of system be used throughout XOTcl and thus have
> > [self] return the alias too, instead of the actual instance? As
> > mentioned, this could potentially solve the issue with object movement.
>
try it out, make up your mind. As shown, a few lines of code can already
implement most of the work,
"self" can be reimplemented in tcl as well with little effort to return
the (or one of the) aliases.
the xotcl regression test is already a good benchmark and testing base.
>
>
> I was wondering the same thing. What would be the impact on XOTcl's
> implementation if an object's location in Tcl's namespace hierachy was
> invariant, and user access to the object was always indirected through
> an alias? I would guess that it's not worthwhile just for "move"
> functionality, but would this guarantee make any other things
> possible, easier, or more efficient?
>
I do not see much evidence of a speed increase when adding a layer of
indirection for every object access.
if the goal of such a project is "everything should be the same as in
xotcl now, but move should be faster",
then i would estimate a man-month of work of somebody with some
tcl/xotcl c-level experience (like uwe or me).
without looking into the details, i would expect problems from
instrospection (including call stack),
namespace handling (namespace import/exports, namespace completion),
dynamic aggregation
(creation, cleanup, semantics, when e.g. an alias is moved), and most
probably many more hurldes
will show up when going into the details. In general, it is possible to
have multiple aliases (references) pointing
to a physical object, in some cases you are interested in the namespace
of the reference(s), in others in the
namespace of the object.
alltogether, it is certainly an interesting exercise considering such a
strucure in general (therefore
i wrote the simple example). However, one could go much further:
Thinking loudly:
Since xotcl objects/classes are tcl_objs pointing to a c-structure
representing the object/classes in c,
and the tcl_objs are refcounted refcounted, i would think there could be
ways achieving the flexibiliy
even without indirection. Currently, these tcl_objs are bound to a
single tcl-command. The aliasing
effect could be achived in theory by using these tcl_objs in multiple
tcl commands. I would
expect some deeper changes here: what happens, if a child object is
added under one name of
the object; will this be visible for another name of the same object as
well? If we continue to
see an object as a object tree, it should. i expect here the same
problems with namespaces as
indicated earlier with the namespace rename command.
-gustaf neumann
>
> Scott
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
Date: Sat, 18 Mar 2006 21:39:35 +0100
Scott Gargash schrieb:
>
> xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/18/2006 01:45:12 AM:
>
> >
> > On 18 Mar 2006, at 02:48, Gustaf Neumann wrote:
> >
> > > so, now we can test the aliased content. it behaves in many respects
> > > the same, but when it comes to refer to "self" or to namespaces
> > > one would notice a different behavior:
> >
> > Could this kind of system be used throughout XOTcl and thus have
> > [self] return the alias too, instead of the actual instance? As
> > mentioned, this could potentially solve the issue with object movement.
>
try it out, make up your mind. As shown, a few lines of code can already
implement most of the work,
"self" can be reimplemented in tcl as well with little effort to return
the (or one of the) aliases.
the xotcl regression test is already a good benchmark and testing base.
>
>
> I was wondering the same thing. What would be the impact on XOTcl's
> implementation if an object's location in Tcl's namespace hierachy was
> invariant, and user access to the object was always indirected through
> an alias? I would guess that it's not worthwhile just for "move"
> functionality, but would this guarantee make any other things
> possible, easier, or more efficient?
>
I do not see much evidence of a speed increase when adding a layer of
indirection for every object access.
if the goal of such a project is "everything should be the same as in
xotcl now, but move should be faster",
then i would estimate a man-month of work of somebody with some
tcl/xotcl c-level experience (like uwe or me).
without looking into the details, i would expect problems from
instrospection (including call stack),
namespace handling (namespace import/exports, namespace completion),
dynamic aggregation
(creation, cleanup, semantics, when e.g. an alias is moved), and most
probably many more hurldes
will show up when going into the details. In general, it is possible to
have multiple aliases (references) pointing
to a physical object, in some cases you are interested in the namespace
of the reference(s), in others in the
namespace of the object.
alltogether, it is certainly an interesting exercise considering such a
strucure in general (therefore
i wrote the simple example). However, one could go much further:
Thinking loudly:
Since xotcl objects/classes are tcl_objs pointing to a c-structure
representing the object/classes in c,
and the tcl_objs are refcounted refcounted, i would think there could be
ways achieving the flexibiliy
even without indirection. Currently, these tcl_objs are bound to a
single tcl-command. The aliasing
effect could be achived in theory by using these tcl_objs in multiple
tcl commands. I would
expect some deeper changes here: what happens, if a child object is
added under one name of
the object; will this be visible for another name of the same object as
well? If we continue to
see an object as a object tree, it should. i expect here the same
problems with namespaces as
indicated earlier with the namespace rename command.
-gustaf neumann
>
> Scott
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>