foreach

Le 11 apr 2013 à 17:15, Jim Barnett a écrit :

>  On the issue of iteration order, isn't it a bit restrictive to require that all implementations use the order that their ecma interpreter chooses?  I assume that most implementations will do that, but I don't see a reason to require them to.

OK, you're right.

> Why  not say:  "In cases where ECMAScript specification defines the iteration order for the object, the Processor MUST follow that ordering.  (Note that for Arrays and strings, this goes from 0 to length-1.)  In cases where the ECMAScript specification does not define the iteration order, the Processor MAY follow any order that it chooses."

Almost. We talk about the order of iteration, but say nothing of what will be enumerated by it if the array is not a string or Array.

As I said before, iterating over ECMAScript objects will enumerate their enumerable properties AND the enumerable properties in their prototype chain. For example (and this is a real-life one), if the author extends the Array prototype with a contains() method, the for…in construct will enumerate, in the correct order, the indexed properties of any array, but will also enumerate the inherited "contains" property.
As you can imagine, that is almost always undesirable and annoying. And it would be annoying to have to add the <if cond="array.hasOwnProperty(index)"> element every time, especially when "array" is not a left-hand-side expression. In the case of Arrays, the spec restricts the iteration to indexed properties, but the same problem occurs with any object whose prototype has been extended.

So I would add that "the implementation *should* only enumerate the object's own properties."

The typed array objects (used for WebGL and the Web Audio API, among other things), are not instaceof Array, and have built-in enumerable own properties that are not indexes. But I can't see a good enough reason to do your audio/video processing in SCXML and therefore no need to specifically mention those typed arrays in the spec.

			David

Received on Tuesday, 16 April 2013 11:06:42 UTC