Non-extensibility of Typed Arrays
dslomov at chromium.org
Thu Sep 5 02:56:13 PDT 2013
On Thu, Sep 5, 2013 at 4:29 AM, Filip Pizlo <fpizlo at apple.com> 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
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
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...
More information about the es-discuss