Scott Gargash schrieb:
xotcl-bounces@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@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl