<html><body>
<p><tt>Thanks for your patience with me and my ignorance. I had inferred that XOTcl was using Tcl namespaces for storing object attributes (methods/variables/aggregations), but in my limited usage I didn't realize that that was (legally) being used to advantage (making plain tcl commands become xotcl methods via namespace import or the like). So far I've been assuming the only legal way to manipulate the object was through its handle (the object command).</tt><br>
<br>
<tt>Given my assumption, my thought was that you could cleanly substitute Tcl's namespace mechanism with a hash-table lookup (attribute name -> Tcl_Obj *) for finding object attributes. Since each object would have its own table, so there's no problem with name collisions (a attribute name is scoped by the object you access it through, i.e., each object has its own set of slots), and if an object can only be accessed through its handle, the handle is the only thing that needs to be exposed to the interpreter. None of the attributes would be visible to Tcl at all (Except to the extent XOTcl exposed them. You could still have traces and whatnot, but you'd have to use the object handle to access them). And if the objects were always accessed via a level of indirection, the raw object handle (the true command name) is uninteresting too, so all objects be created with autonames in the same namespace. And that this sort of an implementation (using a custom attribute lookup mechanism instead of leveraging Tcl's) might potentially have some performance wins and/or new feature possibilities.</tt><br>
<br>
<tt>But from your explanation, using Tcl namespaces to store object attributes is not just an implementation decision, it's really part of the interface, so my approach would break XOTcl in varied and uninteresting ways.</tt><br>
<br>
<tt> Scott</tt><br>
<br>
<tt>Gustaf Neumann <neumann@wu-wien.ac.at> wrote on 03/18/2006 06:52:25 PM:<br>
<br>
> Scott Gargash schrieb:<br>
> ><br>
> > Gustaf Neumann <neumann@wu-wien.ac.at> wrote on 03/18/2006 01:39:35 PM:<br>
> > ><br>
> > > I do not see much evidence of a speed increase when adding a layer of<br>
> > > indirection for every object access.<br>
> ><br>
> > Well, for example, it might be possible to get rid of namespaces in <br>
> > the implementation.<br>
> ><br>
> thinking about getting rid of namespaces is a different theme, this can <br>
> be done as well without "strongly aliased objects".<br>
> <br>
> namespaces are pretty essential in tcl. every command name lookup <br>
> works through a namespace. xotcl uses<br>
> tcl-namespaces for methods (procs and instprocs), for variables, and for <br>
> aggregations. certainly, this could be<br>
> implemented differently, frequently we have to fight with namespaces, <br>
> but the idea was to reuse concepts<br>
> from tcl in xotcl. Using tcl-namespaces has many advantages as well: <br>
> currently, we can rename tcl-procs<br>
> or tcl-commands to make it methods in xotcl; or we can namespace-import <br>
> procs/cmds from tcl as<br>
> methods/instmethods etc. into xotcl with the standard tcl-commands.<br>
> ><br>
> > If the access to the object is always through the reference and the <br>
> > true object was never visible, you might not have to create a new <br>
> > namespace (on demand or not)<br>
> ><br>
> i can't follow the argument.... what ist the relationship with the <br>
> visibility? namespaces are used for various purposes:<br>
> methods are tcl_procs or tcl-commands and have to "live" somewhere, in <br>
> tcl they live in namespaces.<br>
> one can certainly implement this differently as in tcl, as for example <br>
> using hash-tables only, but this is not<br>
> related to visibility. btw, if you never show the real name to the <br>
> application developer, it will be hard to create<br>
> multiple references other than by creating an alias of the alias.<br>
> > or ever move an existing object to make it a child of another object. <br>
> > The parent/subobject relationship could be inferred from the alias's <br>
> > location in the namespace, or even tracked in child/parent hash tables <br>
> > if you wanted to support object relationships beyond a tree (DAGs), <br>
> > but it would not be a property of the object's location. If objects <br>
> > never moved, everything could live in the same namespace, and just <br>
> > tracked via the object hashes.<br>
> ><br>
> > And is method dispatch done via a command lookup? If so, an invariant <br>
> > method location should allow command lookup to be elided.<br>
> ><br>
> whatever "same namespace" means (see above). note that we have multiple <br>
> identical method names in procs/classes,<br>
> they can't live in the same namespace. if the nesting relationship is <br>
> realized via the namespaces of the aliases,<br>
> these have to be created as well since they will most likely not exist. <br>
> This way, they namespaces are moved<br>
> out of the xotcl objects, but introduced at different places, where they <br>
> are more complicated to manage.<br>
> some interactions with namespaces will be even more complicated as they <br>
> are now: you have to<br>
> deal with cases, where e.g. someome deletes the alias (e.g. via "rename <br>
> myreference {}") or deletes<br>
> the namepace, where the alias lives in.<br>
> ><br>
> ><br>
> > Of course, since I'm the one who keeps asking "How do I do this?" <br>
> > questions, I'm probably completely wrong.<br>
> > BTW, does invocation via an alias have any overhead? I would guess <br>
> > not as it's (seems like) a string->Tcl_Obj mapping, the same as a <br>
> > native command lookup, but I don't know.<br>
> ><br>
> an "interp alias" has a certain overhead, since it is an additional <br>
> command invocation.<br>
> Try the following; if you increment the loop counter in the for loop to <br>
> e.g. 1000,<br>
> you will get a "too many nested evaluations" error. you will see, the <br>
> last test will be<br>
> the slowest by far.<br>
> <br>
> ==========================================================<br>
> proc t {cmd {txt ""}} {<br>
> set n 100000<br>
> set ms [lindex [time [list time $cmd $n] 10] 0]<br>
> puts "[format %7.4f [expr {$ms*1.0/$n}]]ms for $cmd ($txt)"<br>
> }<br>
> <br>
> proc x {} {set x 1}<br>
> interp alias {} myset {} set<br>
> interp alias {} myx {} x<br>
> interp alias {} myx1 {} x<br>
> <br>
> for {set i 1} {$i < 100} {incr i} {<br>
> set i1 [expr {$i+1}]<br>
> interp alias {} myx$i1 {} myx$i<br>
> }<br>
> <br>
> t {set x 1} "set"<br>
> t {myset x 1} "myset"<br>
> <br>
> t {x} "x"<br>
> t {myx} "myx"<br>
> t myx$i1 myx$i1<br>
> ==========================================================<br>
> <br>
> It is however possible to implement zero-overhead aliases<br>
> with the tcl c-api, at least in certain situations, when one does not<br>
> care about someone else replacing commands on the fly with<br>
> global effects. I have implemented such things by myself.<br>
> <br>
> best regards<br>
> -gustaf neumann<br>
> <br>
> <br>
</tt><br>
<tt>> ForwardSourceID:NT00007E9E </tt></body></html>