Jeff Hobbs schrieb:
Gustaf Neumann wrote:
Kristoffer Lawson schrieb:
When XOTcl exits, it seems that the [destroy] method is called on all objects. The first question is whether this is wise .. possibly.
well, it was some work to do so, and i think this is important from the oo-point-of-view.
Some work to enable? The general deletion of a Tcl interpreter will call any associated deletion callback for AssocData and commands. The one exception is for the last interpreter in a "common" shell environment, which doesn't get deleted normally (unless exit is undefined or you compile with -DPURIFY).
i am quite satisfied with the current behavior of tcl. we have various compile flags already in xotcl to control the behavior, mostly for debugging memory leaks etc. (not unisimilar to the -DPURIFY motivation in Tcl core). And yes, we are treating "interp exit" and "last interp exist" differently internally.
If one allocates "external resources" (e.g. temp-files, register on a whiteboard, etc) and deallocates these resources in a destructor, the deallocation should certainly happen, when the program exists gracefully.
The graceful deallocation argument is mostly spurious, as the OS cleans things up on program exit, but freeing of external resources is important.
exactly.
This is why I'm considering fixing that "last interp" exception above.
i am not sure that this would simplify the xotcl exit behavior significantly. The biggest problem was to get the deletion order within a namespace correct. since objects and classes are cmds in a namespace's has table, standard tcl deletion does not care about the deletion order. xotcl has to care about this: if we have for example in a namespace
Class A Class B -superclass A B create b1
we have to destroy first object b1 (since this will call the destructor methods of Class B and A as well), and then the classes A and B. This is slightly more complicated with nested namespaces. Therefore xotcl has to create a topological order from the set of destroy candidates, call the destructors in this order and delete the c-structures in a second round. Btw, a similar topological order is used by the serializer.
best regards -gustaf