No registered users in community xowiki
in last 10 minutes
in last 10 minutes
XOTcl/NX mailing list by object move?
From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 19 Mar 2006 13:08:40 +0200
On 19 Mar 2006, at 00:12, Scott Gargash wrote:
>
> When would you need the namespace of the object? If all you have
> is the reference (the handle is truly opaque), you'd have no
> knowledge of the namespace of the object. Containment would have
> to be implemented instead of just inferred, but if it's implemented
> it could have new properties.
I have only ever needed the namespace of an object which attaching
traces to variables (f.ex. with Tk), but for that it is,
unfortunately quite necessary.
> As an aside, I find Tcl's lack of true references to be one of its
> nagging flaws.
Yes, this is a problem. If Tcl had proper references then we could do
garbage collection for objects. The problem is that Tcl's principle
of everything being a string kind of conflicts with references.
References can be represented as strings, although not very useful
strings, but they really aren't strings. I mean, if the string output
for a reference is 0x123456, but I generated that through some other
string operations (or, say we lose the original Tcl object through
various operations) then that will no longer necessarily work as a
reference if the original is gone.
This is particularly problematic as Tcl still has quite a habit of
losing that original representation which naturally I hope will be
reduced in the future.
/ http://www.fishpool.com/~setok/
Date: Sun, 19 Mar 2006 13:08:40 +0200
On 19 Mar 2006, at 00:12, Scott Gargash wrote:
>
> When would you need the namespace of the object? If all you have
> is the reference (the handle is truly opaque), you'd have no
> knowledge of the namespace of the object. Containment would have
> to be implemented instead of just inferred, but if it's implemented
> it could have new properties.
I have only ever needed the namespace of an object which attaching
traces to variables (f.ex. with Tk), but for that it is,
unfortunately quite necessary.
> As an aside, I find Tcl's lack of true references to be one of its
> nagging flaws.
Yes, this is a problem. If Tcl had proper references then we could do
garbage collection for objects. The problem is that Tcl's principle
of everything being a string kind of conflicts with references.
References can be represented as strings, although not very useful
strings, but they really aren't strings. I mean, if the string output
for a reference is 0x123456, but I generated that through some other
string operations (or, say we lose the original Tcl object through
various operations) then that will no longer necessarily work as a
reference if the original is gone.
This is particularly problematic as Tcl still has quite a habit of
losing that original representation which naturally I hope will be
reduced in the future.
/ http://www.fishpool.com/~setok/