On Wed, 04 Jun 2008 19:09:17 +0200, Norbert Hartl wrote:
On Wed, 2008-06-04 at 10:32 +0200, Klaus D. Witzel wrote:
On Wed, 04 Jun 2008 09:55:11 +0200, Norbert Hartl wrote:
On Wed, 2008-06-04 at 00:04 -0400, Rob Rothwell wrote:
Hello,
After much help already, I think I need some training in proper
object
removal.
When my application creates an object and stores it in an OrderedCollection, and than wants to delete it, I am trying to do so quite explicitly with something like:
DataManager>>deleteSelectedAbstractors self selected do: [:each | self abstractors remove: each. each := nil. ]
which removes the object from my application (it's collection), and yet when I look for my object in the system with
DataAbstractor allInstances.
I still see the object I removed, even with an explicit Smalltalk garbageCollect or garbageCollectMost. Anything I create just seems
to
hang around forever.
Any help understanding what I need to do to make sure my objects really go away when I am done with them would be greatly appreciated!
The objects are still referenced in the collection you get from self selected. The line with "each := nil" is useless as each is only a temporary variable.
Not 100% useless, since temporary variables (and arguments, for that matter) survive any attempt, from within the same method, to garbage collect them:
{'this ', 'and ', 'that'} collect: [:each | ]. Smalltalk garbageCollect. {thisContext tempAt: 1} inspect
first line: create some object and make a temp var point to it. second line: invoke GC. third line: see what's still pointed to by the temp var.
Ok, you confused me completely. I was baffled getting a bytestring containing 'this and that'. Shortly after I recognized the commata in your Array assignment. I think you meant
{'this'. 'and'. 'that}
Oh :) I didn't think about commata or periods; why not: both serve the example equally well, a *nonempty* collection expressed with {} ;)
Isn't this an issue of BlockContext?
Yes, and it could be avoided by, as indicated earlier, separating the removal-part (and its block with argument) from the GC+check part (putting both parts in their own method).
Through a similar effect I used to learn fixTemps. Would this be the same behaviour using full closures?
Right, full block closures are supposed go away at GC time (incl. their args and temps) when no longer referenced (as is in the example).
Norbert
/Klaus
I assume that you want to empty the selected collection as well. you could do
DataManager>>deleteSelectedAbstractors self selected copy do: [:each | self abstractors remove: each. self selected remove: each. ]
regards,
Norbert
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners