Non-extensibility of Typed Arrays

Filip Pizlo fpizlo at
Tue Aug 27 09:47:11 PDT 2013

> On Aug 27, 2013, at 9:39 AM, Brendan Eich <brendan at> wrote:
>> On Aug 27, 2013, at 9:35 AM, Oliver Hunt <oliver at> wrote:
>> Existing types with magic index properties (other than Array) just drop numeric expandos on the floor so it's logically a no-op.  Unless there was a numeric accessor on the prototype (which non-extensibility does not save you from).
> Those are a problem and an anti-use-case.

But they won't change anytime soon, will they?

So being inconsistent is weird. 

>> My complaint is that this appears to be removing functionality that has been present in the majority of shipping TA implementations, assuming from LH's comment that Chakra supports expandos
> Does anyone care, though?

I do. Placing named properties on arrays makes sense. Consider a matrix implemented as a Float32Array, with named properties telling you the numRows and numCols. Just one example. 

> TA instances having no indexed expandos but allowing named ones is weird. Better to be consistent to users

Consistency would imply doing what other indexed types do. 

> and help implementations optimize further.

I'm not convinced by this. We support named properties and our typed arrays are pretty well optimized in space (three words of overhead) and time (everything gets inlined including allocation). If there is some amazing optimization that non-expansion gives you, and it's so important that the spec needs to account for it, then I'd love to hear what that is. 

> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list