Implement TypedArray.slice().

Implement TypedArray.slice().

BUG=v8:3578

[bnoordhuis, 2015-05-01 10:59:51]

ben@strongloop.com changed reviewers:
+ dslomov@chromium.org

[arv (Not doing code reviews), 2015-05-01 14:09:30]

arv@chromium.org changed reviewers:
+ arv@chromium.org

[arv (Not doing code reviews), 2015-05-01 14:09:30]

Europe is on vacation today.

I'm looking at the spec for this and I feel like there are few parts missing
here

- The spec covers the case where the type changes, as in:

UInt32Array.prototype.slice.call(int32ArrayInstance, start, end)

- I don't see @@species in here? If we write new methods we should do them right
from the beginning.
- I don't see code checking for detached buffer?.

https://codereview.chromium.org/1113363002/diff/1/src/typedarray.js
File src/typedarray.js (right):

https://codereview.chromium.org/1113363002/diff/1/src/typedarray.js#newcode151
src/typedarray.js:151: if (!(%_ClassOf(this) === 'NAME')) {
This is not quite right. We need to use ValidateTypeArray here.

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-validatetypedarray

https://codereview.chromium.org/1113363002/diff/1/test/mjsunit/harmony/typeda...
File test/mjsunit/harmony/typedarrays.js (right):

https://codereview.chromium.org/1113363002/diff/1/test/mjsunit/harmony/typeda...
test/mjsunit/harmony/typedarrays.js:124: var a1 = new Uint32Array(initialLen);
Maybe pass the constructor to this function so that we can test more than
Uint32Array?

[caitp (gmail), 2015-05-01 14:11:55]

On 2015/05/01 14:09:30, arv wrote:
> Europe is on vacation today.
> 
> I'm looking at the spec for this and I feel like there are few parts missing
> here
> 
> - The spec covers the case where the type changes, as in:
> 
> UInt32Array.prototype.slice.call(int32ArrayInstance, start, end)
> 
> - I don't see @@species in here? If we write new methods we should do them
right
> from the beginning.
> - I don't see code checking for detached buffer?.

Does V8 have a concept of a detached buffer currently? I was looking at this
last week and it didn't look like it was needed yet

> 
> https://codereview.chromium.org/1113363002/diff/1/src/typedarray.js
> File src/typedarray.js (right):
> 
> https://codereview.chromium.org/1113363002/diff/1/src/typedarray.js#newcode151
> src/typedarray.js:151: if (!(%_ClassOf(this) === 'NAME')) {
> This is not quite right. We need to use ValidateTypeArray here.
> 
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-validatetypedarray
> 
>
https://codereview.chromium.org/1113363002/diff/1/test/mjsunit/harmony/typeda...
> File test/mjsunit/harmony/typedarrays.js (right):
> 
>
https://codereview.chromium.org/1113363002/diff/1/test/mjsunit/harmony/typeda...
> test/mjsunit/harmony/typedarrays.js:124: var a1 = new Uint32Array(initialLen);
> Maybe pass the constructor to this function so that we can test more than
> Uint32Array?

[arv (Not doing code reviews), 2015-05-01 15:10:01]

On 2015/05/01 14:11:55, caitp wrote:
> > - I don't see code checking for detached buffer?.
> 
> Does V8 have a concept of a detached buffer currently? I was looking at this
> last week and it didn't look like it was needed yet

I would think so since Blink supports them.

[domenic, 2015-05-01 16:06:17]

On 2015/05/01 at 14:09:30, arv wrote:
> Europe is on vacation today.
> 
> I'm looking at the spec for this and I feel like there are few parts missing
here
> 
> - The spec covers the case where the type changes, as in:
> 
> UInt32Array.prototype.slice.call(int32ArrayInstance, start, end)
> 
> - I don't see @@species in here? If we write new methods we should do them
right from the beginning.

My understanding of the current V8 implementation is that none of the methods
are generic, nor do they exist on a shared prototype (thus the macro setup). I
think someone should fix that, but in the meantime it seems somewhat OK to add
new methods that follow the pattern of the old methods.

[caitp (gmail), 2015-05-01 17:01:16]

On 2015/05/01 16:06:17, domenic wrote:
> My understanding of the current V8 implementation is that none of the methods
> are generic, nor do they exist on a shared prototype (thus the macro setup). I
> think someone should fix that, but in the meantime it seems somewhat OK to add
> new methods that follow the pattern of the old methods.

That's true, but it's still possible to write them as generic even without the
shared prototype --- simply defining the function in a more generic way outside
of the macro, and installing it on each TypedArray class. The shared prototype
issue can be fixed later

[bnoordhuis, 2015-05-01 21:20:37]

I'm retracting this CL.  I looked into the suggested changes but I'm afraid it's
going to take me more time than I can reasonably justify.