Thanks for the reply, I'll let SM and V8 peeps speak for themselves
(they retired my SM number ;-).
Filip Pizlo <mailto:[email protected]>
August 30, 2013 10:41 AM
On Aug 30, 2013, at 9:28 AM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
Hi,
Filip Pizlo <mailto:[email protected]>
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).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
