Sam Ruby rubys at
Wed Jun 2 11:33:57 PDT 2010

On 06/02/2010 02:03 PM, Brendan Eich wrote:
> 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.

"proposed" is a bit more than I had intended.  My intent was merely to 
inquire if the usage of the word "struct" in this context matches the 
usage of that term in another ECMA standard that I was familiar with.  I 
seem to have implied much more than that, for which I apologize.

> 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 .

FWIW, I believe that in C#, both assertions would fail.

> 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

- Sam Ruby

More information about the es-discuss mailing list