Structs

Brendan Eich brendan at mozilla.com
Wed Jun 2 11:03:03 PDT 2010


On Jun 2, 2010, at 7:50 AM, Brendan Eich wrote:

> There's no issue if we separate value types from structs-for-WebGL,  
> but perhaps that is still premature. What I'd like to get back to is  
> "value types are shallowly frozen", though. Otherwise we are  
> introducing a new optimization *and* user-programming hazard to the  
> language, beyond what objects as reference types created.

Sam pointed out in private mail that (my interpretation here)  
regardless of value types being frozen, the structs for WebGL idea has  
aspects of value types -- the structs in a typed array are allocated  
in-line, that's the whole point -- and of reference types via element  
extraction reifying a "view object" by which you can mutate the packed  
data.

So either we lose this refactoring equivalence:

b = a[i];
b.x = 42;
assert(a[i].x === 42);

This assertion botches with Sam's proposed semantics.

Or else we lose the other equivalence, if we reify a struct-view- 
object on element extraction (rvalue):

a[j] = a[i];
a[j].x = 42;
assert(a[i].x === 42);

This example is just like the one above, but uses a[j] for some valid  
index j, instead of a b temporary. Note that with objects (reference  
types), specifically a plain old Array of object instances, the  
assertion holds. But with the sketchy struct semantics I've been  
proposing, typed-array-of-struct elements behave like value types when  
assigned to (lvalues), so this assertion botches .

Structs can't be fully (mutable) value types without breaking one  
equivalence. Yet they can't be reference types or we lose the critical  
in-line allocation and packing that WebGL needs, but this leaves them  
in limbo, breaking another equivalence.

/be


More information about the es-discuss mailing list