On Mon, Jan 9, 2012 at 12:38 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

On Jan 9, 2012, at 8:46 06PM, Levente Uzonyi wrote:

> On Mon, 9 Jan 2012, Mariano Martinez Peck wrote:
>
>>>
>>>>>
>>>>> So..I am puzzle again. I said "In which scenario can � � (self
>>>> instVarsInclude: anObject) �answer true, but the loop false? "
>>>> you answered: "The scenario happens when the receiver has weak slots and
>>>> the argument is referenced from one of those weak slots, but not from the
>>>> other slots."
>>>> Imagine the receiver has a weak slot XXX that points to anObject. So (self
>>>> instVarsInclude: anObject) answers true. � How can the loop answer false
>>>> without a GC?
>>>> why would XXX stop pointing to anObject if there is not GC in the middle ?
>>>>
>>>
>>> The loop doesn't iterate over the indexable slots, only named ones.
>>>
>>>
>> grrr you are right!
>>
>> Ok, so I finally got it. So previously pointersTo: would answer true even
>> if the slots were weak. Now it would answer false, and that's why you have
>> changed the method comment.
>> Now I am thinking if this should be the default behavior of #pointsTo:. If
>> I just read the selector #pointsTo: �I would guess weak references are also
>> taken into account. �So that's why I am not completely sure. Aren't there
>> any other impact of the system because of this change?
>> what about having #stronglyPointsTo: with this new version and have another
>> one #pointsTo: which considers weak also?
>> does it make sense? �or it is better to directly avoid weak by defualt in
>> #pointsTo?
>
> I wasn't sure about this, that's why it's not in Squeak yet. Ignoring weak references is okay as long as these methods are only used for pointer tracing.
>
>
> Levente

Even with a good comment, the naming starts to make little sense, imho�
Does an object having weak slots mean it no longer pointsTo: the objects in those slots?

Sadly, I have no better succinct suggestions. :/

Also, what happens when an object holds its (non-compact) class in a weak slot?

In other words, is:

wa := WeakArray new: 1.
wa at: 1 put: WeakArray.
self assert: (wa pointsTo: WeakArray).

a valid test?

It is vacuous, since WeakArray is referred to indirectly from the roots via Smalltalk and so will not go away. �The following is not a valid test because there could be a GC in between the at:put: and the assert:.

| o oh |

wa := WeakArray new: 1.

o := Object new.

oh := o hash.
wa at: 1 put: o.

o := nil.
self assert: (wa at: 1) hash = oh

but 99 times out of a hundred it'll pass :)

Weak arrays are tricky beasts. �To me, it doesn't matter that when used on WeakArray pointsTo: or instVarsIncludes: or whatever produce results that may be invalid at some subsequent time. �The same is true for e.g. a normal Array that could be updated in some other thread. �It does mater that at the point when an inst var is queried these methods/primitives answer the right answer. �Writing valid tests that verify these answers is another matter entirely. �Don't let the perfect be the enemy of the good.

��

Cheers,
Henry

--
best,

Eliot