2014/1/12 David T. Lewis <lewis at mail.msen.com>

> On Sun, Jan 12, 2014 at 10:50:03AM -0500, Colin Putney wrote:
> > That diff is a bit hard to read, so here's the implementation:
> >
> >
> > allObjectsDo: aBlock
> > "Evaluate the argument, aBlock, for each object in the system
> > excluding SmallIntegers. New objects created by aBlock will
> > be included in the enumeration, and it is up to the caller to avoid
> > creating new objects faster than they are enumerated. It's
> > important that the next object is fetched before the block is
> > evaluated, because the block may use #become: to change the
> > identity of object."
> >
> > | object nextObject |
> > object := self someObject.
> > [nextObject := object nextObject.
> > aBlock value: object.
> > object := nextObject.
> > 0 == nextObject]
> > whileFalse.
> >
> >
> > This version has the following properties:
> >
> > - objects created inside the block will be enumerated
>

I wonder in which case we'd want to do that?
I mean that it's difficult to fully manage (absence of) object creation.
Especially if we insert lazy behaviors which rely on some sort of proxy
(like in Xtreams).
allObjectsThatExistAtThisPointInTimeDo: is a reasonable behavior IMO.


> > - callers may use become inside the block
> > - callers must avoid infinite loop
> >
> > I think these are the most desirable semantics for #allObjectsDo:.
> However,
> > the risk with this implementation is that it will execute an infinite
> loop
> > on VMs that create a new context object for each block activation. Cog
> and
> > the StackVM don't, but John's Mac VM 5.7.4.1 does, according to a quick
> > test I just did. I don't know what the behaviour of older Window and
> Linux
> > VMs are.
> >
> > So  the question is, what VMs are we planning to support for in 4.5, and
> do
> > they recycle activation contexts?
> >
>
> Certainly the up to date interpreter VM and Cog/StackInterpreter will be
> used, but I think that there are some folks who still need to use John's
> Mac VM, so it would be good if we could find a solution that works there
> also.
>
> But I also like your implementation here, it's simple and easy to
> understand.
>
> Dave
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140112/bb909a93/attachment.htm