Non-extensibility of Typed Arrays

Dmitry Lomov dslomov at
Thu Sep 5 02:56:13 PDT 2013

On Thu, Sep 5, 2013 at 4:29 AM, Filip Pizlo <fpizlo at> wrote:

> This is where I return to the objectyness point: typed arrays are already
> spec'd to have a bunch of heavy reference-to-object behavior.  So making
> then expandable is no big deal.  And making then non-expandable means that
> we'll now live in a weirdo world where we have four different concepts of
> what it means to be a value:
> A) Full blown reference objects that you can do weird things to, like add
> properties and change __proto__, etc.  You can also make one non-extensible
> at your discretion, which fits into the bat-poop crazy "you can do
> anything" philosophy of full blown objects.  And that's great - that's the
> heart of the language, and I happen to enjoy it.
> B) Object types that are always non-extensible but otherwise still objecty
> - they have a prototype that is observable, they reveal their identity via
> ==, and you can actually inject stuff into them by modifying the
> appropriate Object.prototype.
> C) Values with whatever value type semantics we come up with in the future.
> D) Primitives.
> Now, I hope that we could get C and D to be as close as possible to each
> other.  But that still leaves three different behaviors.  This introduces a
> learning curve.  That's why (B) offends me.  It's subtly different from (A)
> and clearly different from either (C) or (D).
> Now, we actually also have a totally alternate behavior, used by binary
> data.  And my argument there is that I wouldn't get too offended by binary
> data acting weird, because the very notion of exposing binary data is weird
> to begin with.  I expect it to be used only for special graphicsy stuff and
> not for general-purpose "value types" for normal JS programs.  So it's OK
> to me if binary data is both weird and inconsistent with everything else.
>  And no, I still don't view "typed arrays" as being part of binary data -
> it already appears to be the case that typed arrays have different buffer
> behavior to the struct types.  So they're just different.  And that's fine.
You are underestimating the diversity of species in (A). You *can* create
"full blown reference objects" that are non-extensible in plain JavaScript
today: just call Object.preventExtensions(this) in constructor!
So (B) *as you define it* is a subset of (A).

Note however that typed arrays as implemented by many vendors today are
neither in (A) nor in (B) - you can extend typed array with _named_
properties, but you cannot extend typed array with _indexed_ properties.
There is no "Object.preventIndexedExtensions", so this sort of
(non-)extensibility is indeed a weird case. If the goal is to reduce the
zoo of object kinds, making typed arrays completely non-extensibie puts
them firmly in (A): they are just full-blown objects that happen to be born
non-extensible - something that is already totally possible in the language

As to binary data acting "weird": it might appear weird, but this is again
the kind of "weirdness" that is possible in JavaScript *today*, as
evidenced by Dave Herman's and mine polyfill:
(almost; there are subtle differences re whether struct fields are data
properties or getters/setters, but the key behaviors of assignments and
equality are modelled accurately).

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

More information about the es-discuss mailing list