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/