[Newbies] Re: Proper object removal

[Klaus D. Witzel]

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 at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/beginners