Non-extensibility of Typed Arrays
brendan at mozilla.com
Fri Aug 30 12:31:53 PDT 2013
Thanks for the reply, I'll let SM and V8 peeps speak for themselves
(they retired my SM number ;-).
> Filip Pizlo <mailto:fpizlo at apple.com>
> August 30, 2013 10:41 AM
> On Aug 30, 2013, at 9:28 AM, Brendan Eich <brendan at mozilla.com
> <mailto:brendan at mozilla.com>> wrote:
>>> Filip Pizlo <mailto:fpizlo at apple.com>
>>> August 28, 2013 11:01 PM
>>> Here's the part that gets me, though: what is the value of
>>> disallowing named properties on typed arrays? Who does this help?
>> You've heard about symmetry with struct types (ES6), right? Those do
>> not want expandos. We could break symmetry but at some cost. Too
>> small to worry about? Outweighed by benefits?
> It's a fair point. I don't see where it would break semantics but
> I'll try to do a thought experiment to see if it makes things
> confusing or inconvenient to the programmer. Whether or not I care
> depends on the answers to the following questions:
> 1) Is the purpose to simplify programming by allowing you to add
> static typing?
No, we put a stake through that cold heart.
> 2) Are we trying to help JITs?
Yes, I think so (SM retirement makes this easy for me to say ;-). Even
excluding type inference as done in SpiderMonkey, just using PICs,
structs over against objects can help JITs avoid boxing values, same as
typed arrays do compared to Arrays.
Sometimes you want a product of different types, not a vector of
same-typed elements. Typed arrays were designed so you would alias two
views, crazypants. Structs put on sanepants. Just making sure the
use-case has clear motivation here.
If so, then the JIT wins implemented today among multiple engines for
typed array element loads and stores will almost certainly be wanted for
struct field traffic too.
> 3) Do we just want a sensible way of mapping to binary data? (For
> both DOM and C-to-JS compilers)
Yes, and don't forget the GPU as well ("DOM" doesn't take that in).
More information about the es-discuss