Non-extensibility of Typed Arrays

Andreas Rossberg rossberg at
Wed Sep 4 09:03:03 PDT 2013

On 4 September 2013 17:11, Filip Pizlo <fpizlo at> wrote:
>> On Sep 4, 2013, at 7:55 AM, Andreas Rossberg <rossberg at> wrote:
>>> On 4 September 2013 16:44, Filip Pizlo <fpizlo at> wrote:
>>> On Sep 4, 2013, at 3:05 AM, Andreas Rossberg <rossberg at> wrote:
>>>> As part of binary data, typed arrays are implicitly constructed "on
>>>> the fly" as views on a backing store. Any notion of identity -- which
>>>> is the prerequisite for state -- is not particularly meaningful in
>>>> this setting.
>>> Are you proposing changing how == and === work for typed arrays?  If not
>>> then this whole argument is moot.
>> No, they are just rather useless operations on data views. That
>> doesn't make the argument moot.
> The point is that as soon as you're using the copy '=' on binary data
> fields, you're already losing an observable notion of object identity.  The
> '=' here is already unlike the '=' operator for languages that have true
> value types - in those languages you wouldn't be able to observe if you got
> the *same* typed array or a different one but with the same underlying data.
> In JS you will be able to observe this with '==' and '==='.  Hence, being
> able to also observe that you got a different one because you lost some
> meta-data (i.e. custom named properties) doesn't change the fact that the
> quirky semantics were already observable to the user.

I didn't say it's unobservable -- every twist in the gut is observable
in JavaScript. I said it's rather meaningless. That is, from a
practical perspective, I'd rather not recommend relying on it, unless
you are up for subtle and brittle code.

> As far as I can tell, this object model compresses typed arrays about as
> much as they could be compressed while also allowing them to be extensible.
> The downside is that you pay a small penalty for typed arrays that have an
> "active" buffer, in the case that you either accessed the .buffer property
> or you constructed the typed array using a constructor that takes a buffer
> as an argument.

I really don't feel like getting into this argument -- as I said it's
a minor point. Just note that the optimisation you suggest might not
be worth it in every VM (i.e., there could be a substantial impedance
mismatch), and moreover, that the above case might be not-so-uncommon.


More information about the es-discuss mailing list