AW: [Xotcl] destroy invoked by object move?

[Gustaf Neumann]

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