No registered users in community xowiki
in last 10 minutes
in last 10 minutes
XOTcl/NX mailing list by object move?
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 19 Mar 2006 14:53:50 +0100
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
Date: Sun, 19 Mar 2006 14:53:50 +0100
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