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.