better way to loop through array

  • Thread starter liketofindoutwhy
  • Start date
L

liketofindoutwhy

is using

for (var i in arr) { document.write(arr) }

a better way to loop through an array than

for (var i = 0; i < arr.length; i++) { document.write(arr) }

?

Messing with index feels rather basic...

is there a way similar to

arr.each { |x| document.write(x) }
 
J

Joost Diepenmaat

is using

for (var i in arr) { document.write(arr) }

a better way to loop through an array than

for (var i = 0; i < arr.length; i++) { document.write(arr) }


No. It's worse, in general, since it will loop though all properties of
the array, not just the numeric ones.

Compare:

var bla = [ 1,2,3,4];
bla.stuff = "stuff";

for (var k in bla) {
console.log(bla[k]);
}

with

var bla = [ 1,2,3,4];
bla.stuff = "stuff";

for (var k =0; k < bla.length; k++) {
console.log(bla[k]);
}
Messing with index feels rather basic...

is there a way similar to

arr.each { |x| document.write(x) }

Use forEach, with the fallback implementation for primitive browsers:

<http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:
Objects:Array:forEach>
 
R

RobG

is using

for (var i in arr) { document.write(arr) }

a better way to loop through an array than

for (var i = 0; i < arr.length; i++) { document.write(arr) }


For..in is usually shunned because it iterates over all an objects'
properties (including those on its prototype chain), not just the
indexes. That can be dangerous as you may not have control over all
teh code in the page and someone may add extra properties to
Array.prototype or elsewhere that may cause harm.

However, for..in can be an important speed optimisation when dealing
with sparse arrays (which is probably fairly uncommon or can be
designed away). It is also useful where you reall do want to return
all the properties - but then you'll probably be chipped for using an
array where you should be using an object.

Those that don't like the use of for..in on arrays also curse when
someone adds properties claiming it is an abuse of Array. Which leads
to the question why they are so precious about for..in if they never
add properties anyway.

Anyhow, only use it if you know it is safe (e.g. that Array.prototype
hasn't been extended).
 
T

Thomas 'PointedEars' Lahn

RobG said:
is using

for (var i in arr) { document.write(arr) }

a better way to loop through an array than

for (var i = 0; i < arr.length; i++) { document.write(arr) }


Both are hopelessly inefficient ways, to be substituted by

document.write(arr.join(""));

for an Array object referred to by `arr', or, if that object does not have
the `join' property yet,

// mandatory
arr.join = Array.prototype.join;

document.write(arr.join(""));

// optional
delete arr.join;

since JavaScript 1.1, JScript 2.0, ECMAScript Ed. 1, or

document.write(Array.prototype.join.call(arr, ""));

since JavaScript 1.3, JScript 5.5, ECMAScript Ed. 3, see

http://PointedEars.de/es-matrix

As for the latter `for' statement, generally

for (var i = 0, len = arr.length; i < len; i++)

is more efficient than that, since the `length' property access is only
performed once. (Some also argue that ++i would be more efficient than
i++, but it remains a matter for debate as we do not know the internal
optimization algorithm.)

And if backwards iteration order is acceptable,

for (var i = arr.length; i--;)

is even more efficient.
For..in is usually shunned because it iterates over all an objects'
properties (including those on its prototype chain), not just the
indexes.

Incorrect. A for...in statement iterates over all *enumerable* properties
of an object, whether they are inherited through the prototype chain or not.
It does that in *arbitrary order*, which further distinguishes it from
`for' iteration.
[...]
Those that don't like the use of for..in on arrays also curse when
someone adds properties claiming it is an abuse of Array. Which leads
to the question why they are so precious about for..in if they never
add properties anyway.

The object could have host-defined enumerable properties that we cannot know
about.
Anyhow, only use it if you know it is safe (e.g. that Array.prototype
hasn't been extended).

It is only safe on Array objects if iteration order is irrelevant and
neither Array.prototype nor the Array object itself have been augmented with
enumerable properties with names that cannot be type-converted to Number.


PointedEars
 
L

Logos

for (var i in arr) { document.write(arr) }

a better way to loop through an array than
for (var i = 0; i < arr.length; i++) { document.write(arr) }


For..in is usually shunned because it iterates over all an objects'
properties (including those on its prototype chain), not just the
indexes. That can be dangerous as you may not have control over all
teh code in the page and someone may add extra properties to
Array.prototype or elsewhere that may cause harm.

However, for..in can be an important speed optimisation when dealing
with sparse arrays (which is probably fairly uncommon or can be
designed away). It is also useful where you reall do want to return
all the properties - but then you'll probably be chipped for using an
array where you should be using an object.

Those that don't like the use of for..in on arrays also curse when
someone adds properties claiming it is an abuse of Array. Which leads
to the question why they are so precious about for..in if they never
add properties anyway.

Anyhow, only use it if you know it is safe (e.g. that Array.prototype
hasn't been extended).


If you're using a hash rather than an index, wouldn't an Object work
well for for..in? As far as I can tell (just ran a quick snippet), it
only iterates over the added properties, not the inherited ones.

It's what I often do in my own code...hopefully I'm not making a
'hash' of my processing speed that way...<grin>

Tyler
 
L

Lee

(e-mail address removed) said:
is using

for (var i in arr) { document.write(arr) }

a better way to loop through an array than

for (var i = 0; i < arr.length; i++) { document.write(arr) }

?

Messing with index feels rather basic...


Rule of thumb: The way that feels "rather basic" is much
safer and more efficient.

I'm getting tired of cleaning up after Java programmers who
use methods that look cool and hide all the gritty details,
but which do unexpected things below the surface.
("Unexpected" only because they don't have time to read the
documentation, of course).


--
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,143
Messages
2,570,822
Members
47,368
Latest member
michaelsmithh

Latest Threads

Top