Status of Array extras in ECMA 4
On 9/1/07, David Golightly <davigoli at gmail.com> wrote:
I'm curious as to the fate of the famous JavaScript 1.6 Array extras (indexOf, lastIndexOf, forEach, map, filter, every, some) in ECMAScript 4. As a JavaScript developer, I've come to greatly appreciate the functional-style flexibility these methods offer, and have incorporated implementations of them into my everyday JS toolkit. (See: developer.mozilla.org/en/docs/New_in_JavaScript_1.6#Array_extras and www.webreference.com/programming/javascript/ncz/column4/index.html if you're not familiar with the Array extras.)
However, according to the current ECMAScript 4 specification, these methods appear to be missing from Array.prototype:
developer.mozilla.org/es4/spec/chapter_19_native_objects.html#array_objects
Please don't read that spec, it's seriously out of date. It really needs to be removed.
Given the significant performance boost from moving this sort of iteration into machine code from interpreted code,
I don't agree with that assertion at all (or, I don't agree that ECMAScript implementations are necessarily "interpreted", most are compiling to byte code now and some are compiling to native code). And even so, the overhead of calling the user function and collecting the results is likely to dominate the running time of these functions.
I for one would greatly appreciate an official endorsement of these methods in ECMAScript 4. They certainly seem to fit within the spirit of the existing ECMAScript 3 native array methods (slice, splice, etc.) and have parallels in the String prototype (indexOf, lastIndexOf). Is there a reason not to include them in ECMA 4? If so, what might that be?
They are included in the language.
On 9/1/07, Lars T Hansen <lth at acm.org> wrote:
On 9/1/07, David Golightly <davigoli at gmail.com> wrote:
Given the significant performance boost from moving this sort of iteration into machine code from interpreted code,
I don't agree with that assertion at all (or, I don't agree that ECMAScript implementations are necessarily "interpreted", most are compiling to byte code now and some are compiling to native code). And even so, the overhead of calling the user function and collecting the results is likely to dominate the running time of these functions.
Ok, I was going comparing Firefox 2.0's native implementation of Array.prototype.forEach against their JavaScript version (eg from here: developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Objects:Array:forEach#Compatibility), which though exactly compatible, adds a factor of roughly 1.2 to the linear execution time of the native version (according to my informal benchmarks). I realize that some current ECMAScript 3+ and most upcoming ECMAScript 4 implementations will likely be much more performant even than that.
I for one would greatly appreciate
an official endorsement of these methods in ECMAScript 4. They certainly seem to fit within the spirit of the existing ECMAScript 3 native array methods (slice, splice, etc.) and have parallels in the String prototype (indexOf, lastIndexOf). Is there a reason not to include them in ECMA 4? If so, what might that be?
They are included in the language.
Good news! Thank you!
(typed too fast and missed the redirection to ES4 list)
Hi,
[...]
However, according to the current ECMAScript 4 specification, these methods appear to be missing from Array.prototype:
developer.mozilla.org/es4/spec/chapter_19_native_objects.html#array_objects
please check this link instead spec:chapter_19_native_objects
afaik, the current AS3 implementation provide some (if not all) of the Array "extra" methods the ES4 milestone 0 provide also those Array "extra"
and if the Array class stays dynamic
nothing will prevent you to add the extras you would need
ex: reduce which appears in JS 1.8 is not there (yet)
Array2.as (code from developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Objects:Array:reduce )
package extensions {
public var Array2:Boolean = true;
trace( "Array extensions loaded" );
Array.prototype.reduce = function( fun:Function, ...args ):*
{
var len:uint = this.length;
// no value to return if no initial value and an empty array
if( len == 0 )
{
throw new TypeError();
}
var i:int = 0;
if( args.length > 0 )
{
var rv:* = args[0];
}
else
{
do
{
if (i in this)
{
rv = this[i++];
break;
}
// if array contains no values, no initial value to return
if (++i >= len)
{
throw new TypeError();
}
}
while (true);
}
for( ; i < len; i++ )
{
if (i in this)
{
rv = fun.call(null, rv, this[i], i, this);
}
}
return rv;
}
}
and use it like that
package { import flash.display.Sprite;
public class sandbox3 extends Sprite
{
public function sandbox3()
{
import extensions.Array2;
var total:* = [0, 1, 2, 3].reduce( function(a:*, b:*):*
{return a + b;} ); trace( total );
var flattened:* = [[0,1], [2,3], [4,5]].reduce(
function(a:,b:):* {return a.concat(b);}, [] ); trace( flattened );
}
}
}
just to say that in AS3 you can already add those extras and in ES4 final you will still be able to do that and even more
zwetan
I'm curious as to the fate of the famous JavaScript 1.6 Array extras (indexOf, lastIndexOf, forEach, map, filter, every, some) in ECMAScript 4. As a JavaScript developer, I've come to greatly appreciate the functional-style flexibility these methods offer, and have incorporated implementations of them into my everyday JS toolkit. (See: developer.mozilla.org/en/docs/New_in_JavaScript_1.6#Array_extras and www.webreference.com/programming/javascript/ncz/column4/index.html if you're not familiar with the Array extras.)
However, according to the current ECMAScript 4 specification, these methods appear to be missing from Array.prototype:
developer.mozilla.org/es4/spec/chapter_19_native_objects.html#array_objects
Given the significant performance boost from moving this sort of iteration into machine code from interpreted code, I for one would greatly appreciate an official endorsement of these methods in ECMAScript 4. They certainly seem to fit within the spirit of the existing ECMAScript 3 native array methods (slice, splice, etc.) and have parallels in the String prototype (indexOf, lastIndexOf). Is there a reason not to include them in ECMA 4? If so, what might that be?
Thanks,
David Golightly