Non-extensibility of Typed Arrays

Filip Pizlo fpizlo at
Fri Aug 30 18:35:31 PDT 2013

On Aug 30, 2013, at 4:42 PM, David Herman <dherman at> wrote:

> On Aug 30, 2013, at 4:20 PM, Filip Pizlo <fpizlo at> wrote:
>> This is the kind of weirdness that I hope struct types *don't* have, if their alleged purpose is to help people optimize their code.
> This is a great point, thanks. On the one hand, I concluded long ago the exposure of the buffer seems like something we can't really avoid, since it's necessary for WebGL arrays-of-structs, which is a main use case. On the other hand, that doesn't necessarily mean we need the ability to overlay a struct type into random points in a buffer. We'd have to do this carefully, though: I believe we'd have to restrict overlaying to just the legacy typed array constructors, not to any new kinds of array types (since they may have structs nested inside them), in order to guarantee lack of aliasing. And then we'd want to make sure this covered the WebGL use cases.

I think it's better if you pick one use case and get it totally right.  You're not going to get the "optimize my JS code with types" use case right.  So stick to the binary data mapping use case, and allow arbitrary aliasing.


>> Now, I don't object to typed arrays having this behavior - it is what it is, and it's certainly useful for doing graphics type stuff.  It's also indispensable for emscripten.  And I'm OK with struct types also having this behavior; in fact I would *expect them to have such behavior* if they're supposed by help C-to-JS code generators or the like.
> Not really for C-to-JS, no. I do want them to be useful for e.g. Java-to-JS code generators, but those shouldn't need the casting.
> Dave

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

More information about the es-discuss mailing list