views:

76

answers:

3

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 http://stackoverflow.com/questions/618966/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?

+2  A: 

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.

AndreaG
Yes, creating a copy and changing that does work (that was my solution as well). But does it really make sense that when iterating over properties of an object that changing the value that property points to, would changed the iteration order?
Richard Jones
I think it does. That is, since you are doing a bad thing (changing things while you are reading them), nothing is guaranteed anymore.
AndreaG
+1  A: 

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.

Simon Groenewolt
So we are all agreed about what is happening, and a workaround for it. Hopefully this can help someone else in the future if they have the same issue.My new question is, does this behavior make sense? Or is this an implementation bug on their part?
Richard Jones
A: 

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 ...

back2dos