AW: [Xotcl] destroy invoked by object move?

[Scott Gargash]

Gustaf Neumann <neumann at wu-wien.ac.at> wrote on 03/18/2006 01:39:35 PM:
>
> I do not see much evidence of a speed increase when adding a layer of
> indirection for every object access.

Well, for example, it might be possible to get rid of namespaces in the implementation. If the
access to the object is always through the reference and the true object was never visible, you
might not have to create a new namespace (on demand or not) or ever move an existing object to make
it a child of another object.  The parent/subobject relationship could be inferred from the alias's
location in the namespace, or even tracked in child/parent hash tables if you wanted to support
object relationships beyond a tree (DAGs), but it would not be a property of the object's location.
If objects never moved, everything could live in the same namespace, and just tracked via the object
hashes. And is method dispatch done via a command lookup? If so, an invariant method location should
allow command lookup to be elided.

Of course, since I'm the one who keeps asking "How do I do this?" questions, I'm probably completely
wrong.
BTW, does invocation via an alias have any overhead?  I would guess not as it's (seems like) a
string->Tcl_Obj mapping, the same as a native command lookup, but I don't know.

> 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.

I can't imagine it's a useful effort simply to optimize "move", and I'd also guess that some things
might be faster, some would be slower, and some would be incompatible with such a design.  It would
have to have more payoff than speeding up "move" to to justify it.

> 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.

When would you need the namespace of the object?  If all you have is the reference (the handle is
truly opaque), you'd have no knowledge of the namespace of the object.  Containment would have to be
implemented instead of just inferred, but if it's implemented it could have new properties.

This is what I meant by making new things possible.  As you say, if you have references you can have
multiple references to the same object.  Object hierarchies could be a directed graph instead of a
tree.  I can imagine cases where that would be useful. (I can also imagine cases where it's a
bug...)

As an aside, I find Tcl's lack of true references to be one of its nagging flaws.

> it is certainly an interesting exercise considering such a
> strucure in general (therefore i wrote the simple example).

Yes,  this is just a thought experiment, not a proposal.

> 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.

I agree. I think as long as the implementation and the interface for containment are the same
(namespace aggregation), the renaming problem remains.  The handle needs to be opaque to break the
implementation dependency.

      Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://alice.wu-wien.ac.at/pipermail/xotcl/attachments/20060318/f7f6deb3/attachment.html