<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2014/1/12 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Sun, Jan 12, 2014 at 10:50:03AM -0500, Colin Putney wrote:<br>
> That diff is a bit hard to read, so here's the implementation:<br>
><br>
><br>
> allObjectsDo: aBlock<br>
> "Evaluate the argument, aBlock, for each object in the system<br>
> excluding SmallIntegers. New objects created by aBlock will<br>
> be included in the enumeration, and it is up to the caller to avoid<br>
> creating new objects faster than they are enumerated. It's<br>
> important that the next object is fetched before the block is<br>
> evaluated, because the block may use #become: to change the<br>
> identity of object."<br>
><br>
> | object nextObject |<br>
> object := self someObject.<br>
> [nextObject := object nextObject.<br>
> aBlock value: object.<br>
> object := nextObject.<br>
> 0 == nextObject]<br>
> whileFalse.<br>
><br>
><br>
> This version has the following properties:<br>
><br>
> - objects created inside the block will be enumerated<br></div></div></blockquote><div><br></div><div>I wonder in which case we'd want to do that?<br></div><div>I mean that it's difficult to fully manage (absence of) object creation.<br>
</div><div>Especially if we insert lazy behaviors which rely on some sort of proxy (like in Xtreams).<br></div><div>allObjectsThatExistAtThisPointInTimeDo: is a reasonable behavior IMO.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
> - callers may use become inside the block<br>
> - callers must avoid infinite loop<br>
><br>
> I think these are the most desirable semantics for #allObjectsDo:. However,<br>
> the risk with this implementation is that it will execute an infinite loop<br>
> on VMs that create a new context object for each block activation. Cog and<br>
> the StackVM don't, but John's Mac VM 5.7.4.1 does, according to a quick<br>
> test I just did. I don't know what the behaviour of older Window and Linux<br>
> VMs are.<br>
><br>
> So the question is, what VMs are we planning to support for in 4.5, and do<br>
> they recycle activation contexts?<br>
><br>
<br>
</div></div>Certainly the up to date interpreter VM and Cog/StackInterpreter will be<br>
used, but I think that there are some folks who still need to use John's<br>
Mac VM, so it would be good if we could find a solution that works there<br>
also.<br>
<br>
But I also like your implementation here, it's simple and easy to understand.<br>
<br>
Dave<br>
<br>
<br>
</blockquote></div><br></div></div>