One general observation about our discussion: it is often not clear, what "namespace" refers to, a "tcl namespace" or some kind of an abstract namespace. tcl-namespaces are different to what people understand e.g. in C++ under namespaces. a tcl-namespace consists essentially of a name (fully qualified and simple), three hash-tables, one for vars, one for child-tcl-namespaces, one for commands and some info for managing these (e.g. epoch-handling, namespace resolvers, state-handling during deletion...). see in tclInt.h for more details.
in many respects, tcl-namespaces contain much functionality useful for xotcl objects as well. Allthough tcl-namespaces are no perfect fit in many respects for xocl, it is certainly not useful to duplicate its functionality in xotcl without some very good reasons. i for my part would be happy to have a lower level interface to these functionalities, having e.g. the management for cmds different from the management of the vars, but this would be a deeper change in the tcl-internals, requireing many interface changes.
Kristoffer Lawson schrieb:
On 19 Mar 2006, at 14:09, Scott Gargash wrote:
xotcl-bounces@alice.wu-wien.ac.at wrote on 03/19/2006 04:08:40 AM:
On 19 Mar 2006, at 00:12, Scott Gargash wrote:
When would you need the namespace of the object?
I have only ever needed the namespace of an object
you mean, you needed to use the explicit "requireNamespace", since namespaces are used all over in tcl as discussed in depth. as soon you define e.g. a child object or a proc for an object, a tcl-namespace is automatically added.
which attaching
traces to variables (f.ex. with Tk), but for that it is, unfortunately quite necessary.
I haven't used it yet, but doesn't the "trace" method handle this?
actually, the xotcl trace method does not require an object-specific namespace for variable traces. one can add a trace to an xotcl instvar, alhough this is not in a tcl-namespace.
Where do you see this happening? Do you mean losing the original representation via shimmering, or something else?
I've seen it happen with scripts given to [after]. I was actually very surprised by this, but at some point I was witnessing those scripts becoming strings and thus losing the original Tcl_Objs inside them (the scripts were built as lists).
There are unfortunately many cases, where this happens, even for careful programmers, avoiding obvous cases of shimmering. Unfortunately this tend to happen often in complex situations: i was recently caught be such a behavior in connection with ttrace (demand loading for naviserver/aolserver based on tcl's unknown mechanism), which is by itself quite complex, and it happend only in recursive cases (while resolving one unknown command, another unknown was triggered). I have seen it happen as well with after or other callbacks.
-gustaf neumann
/ http://www.fishpool.com/~setok/
Xotcl mailing list Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl