Non-extensibility of Typed Arrays

K. Gadd kg at
Tue Aug 27 16:14:01 PDT 2013

To me the compelling argument against using encapsulation instead of
extensibility is that it breaks compatibility with existing JS code. Once
you encapsulate an array, the encapsulated object no longer acts like an
array and you can't use it in contexts where a normal array is expected.
The ability to do python style 'quacks like an array' duck typing simply
doesn't exist for arrays in JS.

This is a huge problem for JSIL interop - I can't preserve type information
for arrays, or expose other array features, without either breaking interop
with pure JS or otherwise eating some enormous perf hit (proxies,
spidermonkey's deopt from named slots on arrays, etc). Baking this
limitation into the spec for typed arrays is kind of awful, but I can
understand if it's absolutely necessary...

Maybe WeakMap is the right solution for this? I can't remember what the
performance consequences are for that use case. (Can you use an Array as a
weakmap key? I forget, since it's an object-like type but it has special

Note that I'm not arguing for array subclassing here, just the ability to
'bless' an array instance with extra information. Such use cases are no
doubt fairly rare, even if it's possible to come up with a handful of them.

I assume StructType and ArrayType will address a lot of this, but I'm not
sure how I feel about having to wait for those features when (were typed
arrays specced to allow named expandos) you could do this stuff in a mostly
cross-browser way and ship it right now. (WeakMap fails this test since
IIRC it's still only available in Firefox. :/ I love it and wish I could
use it in the wild!)

On Tue, Aug 27, 2013 at 3:49 PM, David Herman <dherman at> wrote:

> 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?
> Dave
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list