<div dir="ltr">Hi All,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 11, 2014 at 1:51 PM, Florin Mateoc <span dir="ltr"><<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div>
<div>On 1/11/2014 4:29 PM, Colin Putney
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sat, Jan 11, 2014 at 12:11 PM,
Florin Mateoc <span dir="ltr"><<a href="mailto:florin.mateoc@gmail.com" target="_blank">florin.mateoc@gmail.com</a>></span>
wrote:<br>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div><span style="color:rgb(34,34,34)">I
would think that materializing proxies or otherwise
creating new objects within an allObjectsDo: loop is
a bug, just</span><br>
</div>
</div>
as it usually is whenever one grows a collection while
iterating over it. It is the responsibility of the caller
to<br>
ensure that this does not happen.<br>
</blockquote>
<div><br>
</div>
<div>If that's the case, then the caller may not send any
messages to the objects enumerated. That seems overly
restrictive to me. </div>
<div> </div>
<div>
Colin</div>
<div> </div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre></pre>
</blockquote>
<br></div></div>
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.</div></blockquote><div> </div><div>
<p class="">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.</p>
<p class="">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.</p><p class="">
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.</p>
<p class="">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.</p>
<p class="">--</p><p class="">best,</p></div></div><div>Eliot</div>
</div></div>