Support Array and String generic shorthands

• Component: JavaScriptCore
• Status: NEW ---

[Garrett Smith]

Array Generics the built-in Array.prototype methods as generic static methods on the built in Array. 

Array Generics accept an Array-like object as the first argument and return the method of the same name, called in context of the Array-like object.

// Non-generic. 
Array.prototype.slice.call(arrayLike);

// Generic.
Array.slice(arrayLike);

The generic approach reduces clutter and property lookups. It is cleaner and faster.

These methods are implemented in Firefox for quite some time now. For details, please see:
http://developer.mozilla.org/en/docs/New_in_JavaScript_1.6#Array_and_String_generics

Still unimplemented in:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/527.3+ (KHTML, like Gecko) Version/3.1.1 Safari/525.18

[Alexey Proskuryakov]

Re-titling to (hopefully) better match terminology found in aforementioned developer.mozilla.org article. We do support generics, just not the new funny syntax for them.

[Patrick Mueller]

(In reply to comment #1)
> Re-titling to (hopefully) better match terminology found in aforementioned
> developer.mozilla.org article. We do support generics, just not the new funny
> syntax for them.

Just to be clear - I had to try it in a console to be sure - you can call the existing Array methods via Array.prototype.[method].call() and pass Strings.

   > Array.prototype.slice.call("123")
   < ["1", "2", "3"]

[Erik Arvidsson]

(In reply to comment #2)
> (In reply to comment #1)
> > Re-titling to (hopefully) better match terminology found in aforementioned
> > developer.mozilla.org article. We do support generics, just not the new funny
> > syntax for them.
> 
> Just to be clear - I had to try it in a console to be sure - you can call the
> existing Array methods via Array.prototype.[method].call() and pass Strings.
> 
>    > Array.prototype.slice.call("123")
>    < ["1", "2", "3"]

Yes, but it is a verbose and confusing compared to:

Array.slice('123')

That is exactly why Mozilla added these to JS in Firefox 1.5 (?).

[Patrick Mueller]

(In reply to comment #3)
> Yes, but it is a verbose and confusing compared to:

Oh, trust me, I agree!!!

When I first read the bug, I wasn't sure what  Alexey meant by "We do support generics".  Just wanted to clarify that bit, and so added an actual sample.

This shouldn't be too hard to add, should it?  I'd be happy to give it a go ...

[Patrick Mueller]

As my first foray into the JSC impl, I've hacked these in by adding the methods to ArrayConstructor.cpp (copying the pattern from DateConstructor.cpp).  I only did one method, just see if it actually worked; it did.  I copied the map() code from ArrayPrototype.cpp, changing as needed.

But clearly that's not The Right Thing To Do.  Wondering what is:

- copy the relevant functions into a separate cpp, making them externs, and then having ArrayPrototype and ArrayConstructor call into them?

- copy the relevant functions into a .h file as inline, using that .h file in the relevant .cpps?

- lazily lookup the existing ArrayPrototype calls out of the lut.h table, and in the ArrayConstructor code, munge the args and call into the original functions.

- something else

Guess I should also ask if I should even bother.  If I get these implemented in an agreeable fashion, would we even add these methods to Array?  Is there some religious or technical reason we wouldn't?

[Erik Arvidsson]

(In reply to comment #5)
> - copy the relevant functions into a separate cpp, making them externs, and
> then having ArrayPrototype and ArrayConstructor call into them?

This is what I would do but I would hope someone more senior to JSC could chime in.

[Maciej Stachowiak]

(In reply to comment #6)
> (In reply to comment #5)
> > - copy the relevant functions into a separate cpp, making them externs, and
> > then having ArrayPrototype and ArrayConstructor call into them?
> 
> This is what I would do but I would hope someone more senior to JSC could chime
> in.

In general this makes sense, but the extra level of function call overhead could result in a measurable performance regression, so it may be necessary to make the shared code inline.

My main concern about this feature would be whether we want to do something nonstandard - it seems like no one, not even Mozilla, is really pushing this to be in ECMAScript itself. Although we would consider just copying a Firefox extension if it seemed like a really good idea.

[Garrett Smith]

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)

[...]

> My main concern about this feature would be whether we want to do something
> nonstandard - it seems like no one, not even Mozilla, is really pushing this to
> be in ECMAScript itself. Although we would consider just copying a Firefox
> extension if it seemed like a really good idea.

A feature being implemented in multiple implementations and used in applications can provide reason for it to becoming a standard.

Copying this nonstandard feature would be an act of providing reason to for argument of the feature becoming standard. 

If you are seriously considering this route, maybe it would make sense to press the issue es-discuss a little harder beforehand.

[kangax]

FWIW, there's a generics proposal in ES wiki <http://wiki.ecmascript.org/doku.php?id=proposals:static_generics>

Not sure how likely they are to end up in ES harmony (here's a last discussion, which didn't seem to have many nay-votes — https://mail.mozilla.org/pipermail/es-discuss/2009-December/010217.html). It looks like the only holdup is just that no one spec'd them yet.

I'm curious what's the webkit stance on this. Can we have them implemented before harmony?

[Gavin Barraclough]

Looks like an easy fix if we want to do so, but this is currently in the proposal & not harmony:proposal namespace, so it doesn't look like its currently on track to standardization.