On 7 September 2016 at 20:45, stepharo wrote:
> And wht I learned is that we should do
>
>
> ClassOfObjectsThatMustDie allInstances first become: nil
> but really String new.
>
But why a two-way become and not a becomeForward?
And wht I learned is that we should do
ClassOfObjectsThatMustDie allInstances first become: nil
but really String new.
Le 6/9/16 à 02:22, Ben Coman a écrit :
Ohhh... nice... shiny...
That is much easier to remember. Thanks Andres.
cheers -ben
On Tue, Sep 6, 2016 at 5:21 AM, Andres Valloud
Ohhh... nice... shiny...
That is much easier to remember. Thanks Andres.
cheers -ben
On Tue, Sep 6, 2016 at 5:21 AM, Andres Valloud
wrote:
> So why doesn't two-way become: help, e.g.
>
> ClassOfObjectsThatMustDie allInstances first become: String new
>
> As soon as that do-it unwinds there won
So why doesn't two-way become: help, e.g.
ClassOfObjectsThatMustDie allInstances first become: String new
As soon as that do-it unwinds there won't be any references to what the
new string became (the new string wasn't referenced further), so...
On 9/5/16 8:50 , Ben Coman wrote:
Sometimes it
Sometimes its *really* hard to kill some objects. It seems that
inspecting a list of pointersTo creates additional hanging references.
This was frustrating me just now, so I finally hacked a way forward.
Sharing it in case its useful to others, and also I can find it again
searching the list. Thi
