XOTcl/NX mailing list by object move?

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 19 Mar 2006 02:52:25 +0100

Scott Gargash schrieb:
>
> 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.
>
thinking about getting rid of namespaces is a different theme, this can
be done as well without "strongly aliased objects".

namespaces are pretty essential in tcl. every command name lookup
works through a namespace. xotcl uses
tcl-namespaces for methods (procs and instprocs), for variables, and for
aggregations. certainly, this could be
implemented differently, frequently we have to fight with namespaces,
but the idea was to reuse concepts
from tcl in xotcl. Using tcl-namespaces has many advantages as well:
currently, we can rename tcl-procs
or tcl-commands to make it methods in xotcl; or we can namespace-import
procs/cmds from tcl as
methods/instmethods etc. into xotcl with the standard tcl-commands.
>
> 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)
>
i can't follow the argument.... what ist the relationship with the
visibility? namespaces are used for various purposes:
methods are tcl_procs or tcl-commands and have to "live" somewhere, in
tcl they live in namespaces.
one can certainly implement this differently as in tcl, as for example
using hash-tables only, but this is not
related to visibility. btw, if you never show the real name to the
application developer, it will be hard to create
multiple references other than by creating an alias of the alias.
>
> 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.
>
whatever "same namespace" means (see above). note that we have multiple
identical method names in procs/classes,
they can't live in the same namespace. if the nesting relationship is
realized via the namespaces of the aliases,
these have to be created as well since they will most likely not exist.
This way, they namespaces are moved
out of the xotcl objects, but introduced at different places, where they
are more complicated to manage.
some interactions with namespaces will be even more complicated as they
are now: you have to
deal with cases, where e.g. someome deletes the alias (e.g. via "rename
myreference {}") or deletes
the namepace, where the alias lives in.
>
>
> 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.
>
an "interp alias" has a certain overhead, since it is an additional
command invocation.
Try the following; if you increment the loop counter in the for loop to
e.g. 1000,
you will get a "too many nested evaluations" error. you will see, the
last test will be
the slowest by far.

==========================================================
proc t {cmd {txt ""}} {
  set n 100000
  set ms [lindex [time [list time $cmd $n] 10] 0]
  puts "[format %7.4f [expr {$ms*1.0/$n}]]ms for $cmd ($txt)"
}

proc x {} {set x 1}
interp alias {} myset {} set
interp alias {} myx {} x
interp alias {} myx1 {} x

for {set i 1} {$i < 100} {incr i} {
  set i1 [expr {$i+1}]
  interp alias {} myx$i1 {} myx$i
}

t {set x 1} "set"
t {myset x 1} "myset"

t {x} "x"
t {myx} "myx"
t myx$i1 myx$i1
==========================================================

It is however possible to implement zero-overhead aliases
with the tcl c-api, at least in certain situations, when one does not
care about someone else replacing commands on the fly with
global effects. I have implemented such things by myself.

best regards
-gustaf neumann