Non-extensibility of Typed Arrays

Mark S. Miller erights at
Tue Aug 27 16:22:36 PDT 2013

On Tue, Aug 27, 2013 at 4:14 PM, K. Gadd <kg at> wrote:

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

A weakmap key has an unforgeable per-act-of-creation identity, which is the
only requirement. Arrays pass. Strings fail. Interestingly, if we provide a
system-wide interning table from strings to symbols, then internable
symbols fail. Else, unique symbols pass, but have all the problems
previously enumerated.

> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at

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

More information about the es-discuss mailing list