Hi --

On Sat, 30 Aug 2003, Hal Fulton wrote:

> Austin Ziegler wrote:
> > On Fri, 29 Aug 2003 22:02:01 +0900, Dan North wrote:
> >
> >>So it's undefined behaviour, but "Don't modify the receiver while you are
> >>iterating over it." :)
> >>
> >>Can I suggest the solution that Java uses, which is to fail fast in that
> >>situation (ConcurrentModificationException). You would not believe how
> >>much debugging time that one tiny feature has saved me!
> >
> >
> > I wouldn't like that, personally. I don't remember exactly where, but I
> > believe that I have a piece of code taking advantage of the fact that a
> > receiver *can* be modified during iteration. I don't modify during a
> > #collect, but during an #each. One of the things you can do is:
> >
> >   arr.each { |e| arr << f.flatten if f.kind_of?(Array) }
>
> Well, if I understand Matz correctly, this behavior is not guaranteed.
>
> If that's the case, you should change this to avoid being bitten
> the way I was.

I think (Matz - ?) that Matz was talking specifically about changing
the length of the receiver during an iteration, since that raises the
question of how many iterations there should be, what the next one
should be if something gets sliced out, etc.

Just modifying the objects during an iteration is different, I think.
#map! does it, for example.  Or:

  names.each {|name| name.upcase!}

I'm pretty sure there's no danger with in-place things like this
(as opposed to things that alter the meaning of the 'place' you're
'in' :-)


David

-- 
David Alan Black
home: dblack / superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav