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? Cheers, Henry