%TypedArray%.prototype(s)?

# Keith Miller (9 years ago)

I would like to verify my reading of the %TypedArray% Object from the es6 spec. It seems from 22.2.1 that there is a single intrinsic object/prototype that each constructor/instance inherits from, respectively.

Relevant text: “The %TypedArray% intrinsic object is a constructor function object that all of the TypedArray constructor object inherit from. %TypedArray% and its corresponding prototype object provide common properties that are inherited by all TypedArray constructors and their instances.”

Is this the correct reading of the spec? If so, I believe this goes against the current implementation in Safari, Chrome, Firefox, and IE, which have distinct prototypes for each element type.

Additionally, assuming my reading is incorrect, it appears each %TypedArray%.prototype function is required to be sufficiently generic such that it can operate on any of the element types. It was my impression that typed arrays were intended to be as fast as possible, however, requiring a generic implementation contradicts that goal.

# Claude Pache (9 years ago)

Le 23 juil. 2015 à 21:22, Keith Miller <kmiller68 at gmail.com> a écrit :

Is this the correct reading of the spec? If so, I believe this goes against the current implementation in Safari, Chrome, Firefox, and IE, which have distinct prototypes for each element type.

FYI, Firefox does implement %TypedArray%, since version 35 according to: developer.mozilla.org/en-US/Firefox/Releases/35#JavaScript, developer.mozilla.org/en-US/Firefox/Releases/35#JavaScript

Relevant blog post: whereswalden.com/2014/09/26/minor-changes-are-coming-to-typed-arrays-in-firefox-and-es6, whereswalden.com/2014/09/26/minor-changes-are-coming-to-typed-arrays-in-firefox-and-es6

# Allen Wirfs-Brock (9 years ago)

On Jul 23, 2015, at 12:22 PM, Keith Miller wrote:

I would like to verify my reading of the %TypedArray% Object from the es6 spec. It seems from 22.2.1 that there is a single intrinsic object/prototype that each constructor/instance inherits from, respectively.

Each of the nine concrete constructors (%Int8Array%, etc.) directly inherit (via their [[Prototype]] internal slot from %TypedArray%.

Each of the nine concrete constructors have an associated unique prototype object (%Uint8ArrayPrototype%, etc.). Each of those objects inherit (via their [[Prototype]] internal slot from %TypedArrayPrototype%.

Instance of the nin concrete constructors each have their [[Prototype]] initially set to the corresponding intrinsic prototype object. For example the an instance of %Int8Array% will have its prototype set of %Int8ArrayPrototype%

This is all specified in www.ecma-international.org/ecma-262/6.0/#sec-typedarray-constructors, www.ecma-international.org/ecma-262/6.0/#sec-properties-of-typedarray-prototype-objects, www.ecma-international.org/ecma-262/6.0/#sec-properties-of-typedarray-instances

Relevant text: “The %TypedArray% intrinsic object is a constructor function object that all of the TypedArray constructor object inherit from. %TypedArray% and its corresponding prototype object provide common properties that are inherited by all TypedArray constructors and their instances.”

Is this the correct reading of the spec?

yes, as long as you aren't conflating the inheritance of the constructors and the inheritance of the instances

If so, I believe this goes against the current implementation in Safari, Chrome, Firefox, and IE, which have distinct prototypes for each element type.

Prior to ES6 there was no standard specification that fully defined the the proper inheritance hierarchy for these constructors, so implementations did various things. ES6 now provides a standardized hierarchy that all implementations are expect to use.

Note that there is still a distinct prototype object corresponding to each concrete constructor, but it is not visibly populated with the built-in instance methods. Instead they are inherited form %TypedArrayPrototype%.

Additionally, assuming my reading is incorrect, it appears each %TypedArray%.prototype function is required to be sufficiently generic such that it can operate on any of the element types. It was my impression that typed arrays were intended to be as fast as possible, however, requiring a generic implementation contradicts that goal.

Performance is a quality of implementation issue and different implementation may make differing performance trade-offs. An implementation is free to optimize this method using techniques it can come up with, as long as the optimization does not observably violate the specification. For example, each of the common inherited methods might internally dispatch (based upon the element type) to different element-typed specialized implementations of its algorithm. Or an implement that uses PIC might cached a specialized implementation based upon the element type.