Hi All,
On Sat, Jan 11, 2014 at 1:51 PM, Florin Mateoc florin.mateoc@gmail.comwrote:
On 1/11/2014 4:29 PM, Colin Putney wrote:
On Sat, Jan 11, 2014 at 12:11 PM, Florin Mateoc florin.mateoc@gmail.comwrote:
I would think that materializing proxies or otherwise creating new objects within an allObjectsDo: loop is a bug, just as it usually is whenever one grows a collection while iterating over it. It is the responsibility of the caller to ensure that this does not happen.
If that's the case, then the caller may not send any messages to the objects enumerated. That seems overly restrictive to me.
Colin
I am curious how would you implement #nextObject so that you could iterate over all objects in an image even if you create new objects after the first call to #nextObject.
The bug is in implementing allObjects in terms of someObject and nextObject in the first place. It's cheap and cheerful but horribly error-prone and restrictive. It's cheap because the collection of objects doesn't have to be created, and on the original 16-bit Smalltalk machines that was really important. It's horribly restrictive because it assumes much about the implementation.
Before closures a sentinel wasn't even needed because enumerating the block didn't create a new object (the block context was reused). So the code had to be rewritten just to support closures.
Spur has a generation scavenger operating in a distinct new space and that doesn't jive well with a consistent ordering at all. So far the system is limping along by tenuring all objects on someObject and someInstance (so that newSpace is either empty, or doesn't contain any instances of a specific class) and having nextObject enumerate only objects in oldSpace.
But I think now we can afford a primitive that answers all the objects (remember that average object size means that such a collection will be ~ 10% of the heap, average object size in Squeak V3 is about 10.6 words). At least that's what Spur will do, along with an allInstancesOf: primitive. And then the become example won't cause any problems at all. Far more reliable. I suppose there are circumstances when enumerating without a container is the only feasible approach, but VisualWorks has got along with only an allObjects primitive for a long time now. I suspect we can too.
--
best, Eliot