Non-extensibility of Typed Arrays

Filip Pizlo fpizlo at
Wed Sep 4 16:45:03 PDT 2013

On Sep 4, 2013, at 2:41 PM, Brendan Eich <brendan at> wrote:

> Filip Pizlo wrote:
>> I agree that both of these aspects of binary data are quirky.  My observation is that prohibiting custom properties doesn't fix the underlying issue.
>> [snip]
>>>    var MyArray = new ArrayType(...);
>>>    var MyStruct = new ArrayType({f: MyArray});
>>>    var struct = new MyStruct(...);
>>>    var array1 = struct.f;
>>>    var array2 = struct.f;
>>> then `array1` and `array2` would have disjoint sets of extensible
>>> properties.]
>> Yes, they would.  But even if they didn't, then array1 != array2, which is equally odd.
> Both adds up to two, not one, so the counterargument is odd beats odder, and prohibiting expandos keeps the oddness down to == and nothing else.

What about being consistently odd?  To me, 'struct.f' means allocating a new [sic] array buffer view object.  That new object thus has all of the features you'd expect from a new object: it won't have custom properties, it will have some default prototype, and it will not be == to any other object.  Hence if you say " = 42", then "" will subsequently return undefined.  No big deal - it was a new object.

> I'm not trying to persuade you here, just trying to agree on how to do "oddness accounting". It could be that we're better off with the oddness you prefer, for human factors reasons of some kind.

I actually think that this simply isn't going to matter.  Binary data is there for hacking with bits.  Whether a struct.f, which is defined by the user to be an array, is expandable or not isn't going to be a big deal to most people.

On the other hand, empowering users to be able to carry around typed arrays with some extra meta-data could be useful to people.

> But "lost expandos" due to loss of identity are an especially nasty kind of bug to find.

I'm actually curious - are you aware of such bugs, and what do they actually look like?  To me this is analogous to the question of whether an API returns to you the *same* object you passed in earlier, or a new object that is a copy - and my vague recollection of the various APIs and SDKs that I've used over the years is that whenever I see such issues, I make a note of them but never find myself having to think very hard about them.  And they rarely lead to interesting bugs.

> Is there any use-case here? We've never had a bug report asking us to make SpiderMonkey's typed arrays extensible, AFAIK.

I was the one who brought up the use case. ;-)  Say I want a matrix.  I like saying:

function makeMatrix(rows, cols) {
    var result = new Float32Array(rows * cols);
    result.rows = rows;
    result.cols = cols;
    return result;

I realize this is goofy - I could have created a wrapper object around the Float32Array.  But that requires more code, and I've come to enjoy doing this kind of goofiness in scripting languages.

> /be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list