Typed Objects are a huge step forwards but they still have some limitations. I frequently use things like: solverStates = { numVars: uint32 num

Typed Objects are a huge step forwards but they still have some limitations. I frequently use things like: solverStates = { numVars: uint32 numConstraints: uint32 numStates: uint32 solverStates: solverState[numStates] } solverState = { los: uint32[numVars] his: uint32[numVars] constraintStates: *void[numConstraints] } Even using C, dealing with types like this is kind of a pain and would benefit from some macro magic. With Typed Objects it looks like I have to choose between variable sized arrays and pointers - I can't have both because then the gc won't know where to look for the pointers. According to http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects working with such types is an explicit non-goal: > In particular, binary formats often need expressive and dynamic data dependencies that are decidedly out of scope for this API, such as being able to specify an array whose length is determined by a preceding integer That's probably the right decision for js, given the constraints of sane gc implementation. It still looks like my best option is to use asm.js and have full control over layout. Either way, I am grateful that Mozilla continues to push for a fast, open and portable language. I don't have much love for js, but it's a damn sight better than trying to deliver portable native code to non-technical users.