No enumeration order of for..in is not guaranteed From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Tracy Spratt Sent: Wednesday, December 10, 2008 8:55 AM To: [email protected] Subject: RE: [flexcoders] Re: speed of the "for each" looping
Is the enumeration order guaranteed to be the same for for-in and for each as an indexed loop? Tracy ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Cato Paus Sent: Wednesday, December 10, 2008 9:50 AM To: [email protected] Subject: [flexcoders] Re: speed of the "for each" looping if you need to get the i you can use the getItemIndex::ArrayCollection --- In [email protected]<mailto:flexcoders%40yahoogroups.com>, "Amy" <[EMAIL PROTECTED]> wrote: > > --- In [email protected]<mailto:flexcoders%40yahoogroups.com>, "Josh > McDonald" <dznuts@> wrote: > > > > *nods* > > > > I find that it's often much easier to read when you use for..in and > for > > each..in rather than regular for. And since you need to have a "var > current > > = list[i]" or similar as the first line, If you only need an index > to > > display, or it's 1-based as opposed to 0-based, using a "for > [each]..in" and > > having the first inner line be "++idx" will be easier to read than > a bunch > > of statements within your loop that look like: > > > > var current = foo[i+1] > > > > or > > > > msg = "you're at item #" + (i + 1) > > The thing is, I nearly always find I need that i for something else > other than just iterating, so even when I start out with a for each > loop, about 80% of the time I wind up switching back so I have that i > to get hold of. Since I know that this is quite likely to happen, I > just "cut to the chase" and use the indexed loop. > > -Amy >
