Flex/AS3 - Problem with for ... in construct when modifying loop source values

DISCLAIMER: relatively new to Flex/AS3, I might be missing something obvious.

After doing some research it appears that using the for(var property:String in object) does not guarantee the enumeration order of properties, however it doesn't say anything about modifying the 开发者_开发知识库VALUE that property points to as changing the for...in loop. See For-Each Loop AS3: Is the direction guaranteed? for background info.

My example is as follows:

for(var i:int = 0; i<objectArray.length; i++)
{
    for(var property:String in objectArray[i])
    {
        objectArray[i][property] = unescape(objectArray[i][property]);
    }
}

objectArray[i] has properties a, b, c, d, e, f. When I step through the code here I get c, b, d, c, a, f. Notice that I get c twice.

As a solution I can create a temp object to store the data while doing the loop on the original object, and then replace the original object with the modified data, but I'd like to know what exactly is going on.

So my question is, does the value of object property modify the looping order of the for...in construct? And if so, should it or is this a bug?

Altering the contents of a variable you are looping over is rarely a good thing to do. In Java for example you can't iterate over a thing you are modifying.

You should produce a copy, work on the copy and after the loop is over re-assign the new data to the variable in a single instruction.

Your assignments are messing with the iterator order, what to you looks like just the reassignment of a member on an object could be something quite different behind the scenes. I'm guessing the object you are iterating over is not of a sealed class?

As AndreaG mentions you could make your changes on a copy, there is another option if you don't want to change the reference to your original array but don't mind iterating twice.

First iterate over the array to create a (new) array of keys.

Then, iterate over the array of keys and update the values on the original object.

i guess, this choice was made for performance ...

to ensure, that altering the underlying structure doesn't have any effect on iteration would require to extract all keys into a list first, and then iterate over that list ... that makes 1 extra iteration, and also, the first might be unneccessary, if for example you're doing a search operation, which means you'll probably cancel iteration at some point ...