On 16 Mar 2006, at 14:15, Scott Gargash wrote:
I understand that the operation is actually quite expensive, due to current Tcl internals, but is there any reason why a destructor should be called? If we
want
a method called for a move operation, surely it would be simple to define that a "beingMoved" method is then called.
I'm guessing that xotcl::object's "destroy" method does all the heavy lifting (cleaning up the source of the move). What would happen if the default move implementation was to change the source object's class to xotcl::object before invoking destroy? This way it would continue to use the xotcl::object's "destroy" implementation for cleanup purposes without invoking all of the subclass destroy methods, and derived classes wouldn't perceive move as a destroy operation. Would this have bad side-effects?
But I am guessing even this is unnecessary. Why call the destroy at all? I am confident, without looking at the actual code, that deallocation of the resources for the 'original' object could be deallocated without going through the whole destruction procedure.