On Friday 24 January 2003 15:16, Kristoffer Lawson wrote:
On Fri, 24 Jan 2003, Gustaf Neumann wrote:
we could provide an option -bind <varname> to the new instproc to allow the user to specify a local or a per-object or global variable name, but this does not provide reference counting at all. i have started some time ago to work on reference counting, and xotcl has some good prerequirements for this: we have tcl_objs for xotcl objects, they maintain already a reference count. the obvious idea is to destroy the object, when the reference count reaches 0. however, practically this showed to be quite tricky in the current implementation since the refcount = 0 condition happens in some unvonveniant situations... i have not given up on this, but it needs a bigger chunk of time to devote to this...
Yes, exactly. Obviously it's all just steps to make some things easier while refcount based destruction is the absolute solution. However, as you may have noticed from c.l.t, ref-count -based systems are really nasty to get done properly. How would you propose to deal with the situation where a reference is lost, because the object just happens to be made into a string (ie. some command or procedure does not keep the Tcl_Obj but just uses the data as a command). F.ex. when building callback scripts and containing the object handle there, or as an array key (I think array keys are still just considered to be strings and the Tcl_Obj form is not retained).
sure, in general, this is an intrinsic problem. what i have implemented already in 0.94 was a double refcounting, that allows multiple tcl_objs to point to a single xotcl-object (or class), having therefore refcounts on the tcl_objs and separate refcounts on the xotcl-structures (classes and objects). therfore it is possible to convert for example the string "Object" with little effort to he class Object, as long it exists. For example after the statement
Class C -superclass Object
Object is a TclObj pointing to the appropriate xotcl-structure. So, this is not exactly the same situation as the general case, where the string to object mapping is not possible or leads to a new structure not representing the old state.
Certainly, when all references are gone (stringified, only string callbacks point to an object) the object will be destroyed.... still, we would have the choice btwn traditional objects (that can be used safely in callbacks) and refcounted objects, there are many cases, where this might be useful ... i my code, i have not experienced the problem with unneeded objects (people that grew up with Java rather than C might thing differently)
-gusaf