Brendan Eich brendan at
Fri Jun 4 14:05:55 PDT 2010

On Jun 3, 2010, at 2:42 PM, Oliver Hunt wrote:

> My proposal would have you do something along the lines of:
> buffer = new ArrayBuffer({x, y, z: uint32; r, g, b, a: uint8} ) //  
> using your abused syntax
> producing an object where you would do:
> buffer.x[i] = ...;
> buffer.y[i] = ...;
> ...
> buffer.r[i] = ...;
> buffer.g[i] = ...;

Hack-a-rama! :-P

It still seems to me, whether you use overlayed typed arrays that  
users never intentionally use to alias the same given machine-typed  
fields, or a "transpose" of such overlayed typed arrays: monotyped  
arrays that stride with the right skews to access the members; that we  
are just perpetrating the lowest-level hack possible to satisfy the  
immediate use-case, without counting usability costs or considering  
future-hostility to obvious evolutionary pathways.

>> This could all be "optimization", an implementation issue. Except  
>> WebGL needs speed, and this need is evident in the semantics of  
>> proposals such as typed arrays.
>> Ignoring all such optimization guarantees, the shift and OR code is  
>> ugly and verbose. So there's a usability argument to be made for  
>> arrays of structs, if not typed arrays as proposed.
> I'm not sure where this shift/or stuff comes from?

If you could say "use a uint32 vector" but every fourth element was  
not x, y, or z but rather a quadruple of bytes (rgba), then these  
shifts and ORs would be needed. The idea would be to simplify typed  
arrays to monotyped, non-aliasing vectors of machine types.

> My intention was that you end up with a "struct of arrays" rather  
> than an "array of structs" -- internally the implementation would be  
> using flat storage in the form requested.  The exposed accessor for  
> a given field array would be something akin to
> return toJSValue(*(MachineType*)(data + index * structSize +  
> fieldOffset))

a.x[i] instead of a[i].x doesn't really express this computation, but  
never mind. It still seems hard to nest structs or typed arrays in  
structs (in typed arrays), or otherwise future-proof this design.

Vlad had WebGL wish-list examples like this:

typedef struct {
  float32_t x, y, z;
} vec3_t;

typedef struct {
  uint8_t r, g, b, a;
} color_t;

struct {
  vec3_t vertex;
  vec3_t normal;
  color_t color;
} vertex_element_t;

Making people code accesses to such data in some Fortran-ish way is  
just awful. I would rather we do something like a subset of Mozilla's  
jsctypes, designed by Jason Orendorff, mentioned previously:

Some careful thought went into this design. Jason should weigh in here.


More information about the es-discuss mailing list