On Mon, Jan 9, 2012 at 12:38 PM, Henrik Johansen < [email protected]> 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
