On Thu, May 27, 2010 at 12:05 PM, Brendan Eich <[email protected]> wrote: > On May 27, 2010, at 11:38 AM, Sam Ruby wrote: > >>> Well-supported arrays of structs (as schemas) might be a satisfactory >>> compromise. Consensus emerging around that solution. >> >> Structs in ECMA-334 are value types, and consist of members that also are >> value types. Would structs in future revisions of ECMA-262 share these >> characteristics? >> >> Is it fair to assume that there would end up being a more richer set of >> primitives to select from when composing a struct than simply "object", >> "boolean", "number", "string" and the like? Again, ECMA-334 defines the >> following: >> >> http://en.csharp-online.net/ECMA-334:_11.1.5_Integral_types >> >> Would something similar be envisioned for ECMA-262? > > No, we did not envision adding more primitive types, type annotations, > conversion rules, and first-class struct declarations. > > Something more like > > const TA = > Array.newTypedArray(fixed_length, > Object.newStructType({x:"u32", y:"u32", z:"u32", > r:"u8", g:"u8", b:"u8", > a:"u8"})); > let a = new TA(...); > > ... a[i].x ... > > >>> Khronos would like to continue developing their API as WebGL host >>> objects in the meantime. This may lead to forking of APIs in the >>> developers' minds. The possible danger is failure to reuse common >>> abstractions. >>> >>> Need a champion. Waldemar offered to work with Khronos to drive a >>> proposal. > > Dave, Vlad, and Andreas (Vlad is on the WebGL working group and has > implemented WebGL typed arrays in TraceMonkey) are interested in > collaborating too.
I'd also like to collaborate on this and offer one additional point: for WebGL's use case, we will need to be able to query the byte offsets of fields in these structs as well as the byte size of the struct. This is needed in order to make the appropriate OpenGL calls to set up rendering after the data has been assembled and uploaded to the graphics card. -Ken >> If structs are anything like value types, then I am interested in >> participating. I'm particularly interested in working through the details >> of how arithmetic of integer like quantities would work. > > The struct-array idea for WebGL avoids the typed array aliasing design, and > consequent byte-order leakage. But we are not envisioning new operator > overloading or literal syntax. At most a[i].x would be optimized to a very > fast, packed member read or write, after scaling i and adding the offset of > x. Any read would use ES's number type, I believe. > > There's an issue with float32 -- IIRC it does not project into float64 (AKA > double). All the other types (uint32, what I schematically named "u32" > above, etc.) do. > > /be > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
