Hi,
We think that it is (in some cases) a good idea to have something like that. We're especially interested in having scoped objects, as your example down below suggests. That is, objects that persist as long as the proc scope persists. And -- like you -- we believe string based object referencing is a great strength of XOTcl ... therefore, we wouldn't like to have a general garbage collector (which would mean, no string refs anymore).
I'm not sure that Tcl_Objs are the best implementation variant for such a GC scheme, because of (a) shimmering (which may cause at least heavy performance problems) and (b) if some string with the same name exists, the object does not get deleted.
Scoped objects could be quite easily done in XOTcl using the XOTcl callstack in C. That is, reference the scoped objects on the XOTcl callstack and then delete them in CallStackPop ... the disadvantage of this is that only XOTcl procs and instprocs could have scoped objects, not Tcl procs as in the example down below. Probably that won't hurt so much ...
Regarding our plans ... the next steps are: - we work on the patch release (tomorrow ready, hopefully) - I work on a re-implementation of the filter implementation ... we want to have a better implementation & support per-object filter & linearization of filters (as for mixins). This will take a while, since I'm travelling alot these days ;)
Feel free to contact us, if you need any assistance.
--Uwe
On Sunday 20 May 2001 12:39, Artur Trzewik wrote:
Hi
The really problem of Xotcl is, it has no garbage collector. It means you must destroy your object yourself per destroy method.
The garbage collector of such languages as Java, smalltalk, ruby work by tracking references to one object. if no reference point to object, this object is destroyed.
This would not work by xotcl. Xotcl object are localized per name (string) and no reference. (And it is very flexible in most cases) It can by hardly changed. It is pity, if one consider that tcl has internal full garbage collector based on Tcl_Obj (structure) with references counter.
This problem is no so dramatic if one use object aggregation. So the aggregated object is deleted automatically if parent object is to be destroyed. But is can be rather hard by using "short-live" object (for example by implementing special data structures in Xotcl).
The solution of this problem can be to add new create method in Xotcl. To create object to use only as reference. It means object lives only so long if the reference exist. It will use internal standard tcl structures (as Tcl Stings, Integer, Arrays)
example usage
proc exampleScope {} { # create short-live Object for reference set ref [Object newReference] # using object $ref set var 11 # be exit the object referenced by variable ref # will be deleted automatically }
The best think is one can choose to use garbage collector or not.
Object newReference
will for example create one object and destroy it immediately. So in such case the old method
Object new
should be used.
Internal implementation.
The main thing is to tread Xotcl objects in the same way as other tcl objects (Stings, Interger, Array) and use tcl garbage collector I thing there should be a wrapper Tcl_Obj (new Type)
Here only the main idea static Tcl_ObjType XOTclReferenceObjectType = { "XOTclReferenceObject", (Tcl_FreeInternalRepProc *) ourNewDestroyMethod, (Tcl_DupInternalRepProc *) NULL, UpdateStringOfXOTclObject, SetXOTclObjectFromAny };
The newReference method must create such reference Tcl_Obj and return it as result. Of course newReference must be implemented in C in libxotcl.so.
What do you think about it? I mean I can implement it but I am not sure how it would suite to another concepts or future plans. For example for xotcl objects created per newReference the destroy method make no sense. It can make also another problems that should be discused.
=========================================
Artur Trzewik http://www.xdobry.de
=========================================
Xotcl mailing list - Xotcl@wi.wu-wien.ac.at http://wi.wu-wien.ac.at/mailman/listinfo/xotcl