AW: [Xotcl] destroy invoked by object move?

[Gustaf Neumann]

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 at 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 at alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl