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
=========================================
On Sunday 20 May 2001 12:39, Artur Trzewik wrote:
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'd love to see such a thing. A good idea.
Cheer's Zoran
On Sun, 20 May 2001, Artur Trzewik wrote:
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)
You may want to read Paul Duffin's (IIRC) whitepaper on the proposed Feather system. There are a few problems to using an OO system with that kind of reference -based system. This is AFAIK mainly related to various callback scripts where an actual reference to the original object is not being stored but rather just the string. This happens at least with commands like "after". It's not an impossible situation, but is something to keep in mind.
I'm not quite sure where to find the paper, but I believe USENIX's website might be a good bet.
- ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok@fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/
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
On Mon, 21 May 2001, Uwe Zdun wrote:
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.
I believe shimmering will actually be quite a small problem as in Tcl objects the string version of an object is kept anyway and if this does not change, no shimmering should occur at any point. At least this is how I think it happens.
(b) is also not really a problem. With GCed objects the names should also be generated and unique and thus not conflict with other objects. Hm, Tcl should probably provide a way of creating objects which are not shared on the basis of their string content... Maybe this was one of the changes Feather was going to make.
By far the most difficult problem is the fact that many callback systems take strings as scripts and Tcl strings are not currently structured in any way. So for example:
after 1000 {[MyObject new] dostuff}
This will not work with GCed objects. The new MyObject will be GCed immediately after the call to "after". OK, this is contrived, but there are more dangerous situations where this can occur. This was one major problem with the systems in Feather and has to be taken into account. The only long-term solution I can think of is for Tcl to structure strings into trees (sometime in the future) and thus keeping references to objects even when they become a part of another string (and do not exist elsewhere).
I do agree that GCed objects would be a good thing. GC simply makes a lot of things much much easier. I'm not quite sure how critical the above problems are, but it's worth considering. Object aggregation actually removes a lot of the need for GC, but it's not perfect either.
- ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok@fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/