View · Search · Index
No registered users in community xowiki
in last 10 minutes

XOTcl/NX mailing list by object move?

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 17 Mar 2006 17:25:37 +0200

On 17 Mar 2006, at 16:33, Gustaf Neumann wrote:
>
> as pointed out earlier, move is a copy + destroy.
> If you want a copy alone, use copy and not move.

No, I do not want copy alone. It is just counter-intuitive that the
destructor is called on a move as movement is not generally
considered to be an act of desctruction. This would be the norm for
most things. Consider files for example. When a file is moved at no
point does

> As Artur pointed out, command names are the references to objects.
> if such a reference should be made invalid and the unneeded
> storage should be reclaimed at this time, destroy is the correct
> thing.

The matter of references is problematic. I am thinking that in fact
this reveals a downside to the namespace-tied model as handles do not
point to the object itself, but to the object's location within the
namespace universe. A move is not actually a matter of transferring
the ownership of an object to a new location and this slightly limits
the ways you can use XOTcl move functionality for data structures.

Of course one can set variables to detect this, as mentioned, but
this seems like a bit of a hack and fighting against what XOTcl is
doing. Perhaps the question should be asked: how is object movement
actually supposed to be used in XOTcl?

A double-reference would solve this. In that way the handle returned
by [new] and [self] would always be a valid command for the object,
throughout its whole lifetime. If it is moved to be a child of
another object the handle remains the same (or at least can be used),
but the ownership is changed. Whether this is workable in XOTcl or
not is, of course, something you would be better at deciding.

In any case, the destruction should be clearly mentioned in the
documentation as there seems to be a number of people who are
surprised by that.

            / http://www.fishpool.com/~setok/