Non-extensibility of Typed Arrays

David Herman dherman at
Tue Aug 27 15:49:05 PDT 2013

On Aug 27, 2013, at 9:47 AM, Filip Pizlo <fpizlo at> wrote:

> 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. 

There are of course other ways to achieve this that don't involve patching the array object, such as building a data abstraction for matrices that has-a Float32Array, or creating a new array type with additional methods:

    var Matrix = new ArrayType(float32);
    Matrix.prototype.numRows = function() { ... }
    // or
    Object.defineProperty(Matrix.prototype, { get: function() { ... }, ... });

>> 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. 

Consistency arguments won't get you very far. The indexed properties of typed arrays by design act very differently from other indexed types. That's their whole reason for existence.

And the other consistency dimension is between array types and struct types. Is anyone arguing that structs should also have expandos?


More information about the es-discuss mailing list