[Pharo-project] Bug in #pointsTo: ?

Levente Uzonyi leves at elte.hu
Mon Jan 9 15:50:03 EST 2012

On Mon, 9 Jan 2012, Henrik Johansen 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?

Since #pointsTo: doesn't use primitive 132 directly, it's only used from 
the pointer tracing tools, which shouldn't really follow weak references.

> Does an object having weak slots mean it no longer pointsTo: the objects in those slots?

If you mean "points to", then no. :)

> 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?

Yes, because its class pointer points to its class (this sounds funny :)).


> Cheers,
> Henry

More information about the Pharo-dev mailing list