Brendan Eich brendan at
Wed Jun 2 07:50:24 PDT 2010

On Jun 2, 2010, at 4:02 AM, Sam Ruby wrote:

> On 06/02/2010 03:52 AM, Jason Orendorff wrote:
>>> I'll still maintain that the choice that ECMA 334 takes, namely
>>> that the assignment to b in the example above, makes a mutable
>>> copy is a valid choice.
>> I would expect
>>   a[0].x = 3;
>> to modify a[0], not a temporary copy of a[0]. How do you propose to
>> make that work in ES?
> I'll note that that is not the way strings work today:
> a = "abc';
> a[0] = 'x';
> That being said, I'll agree that a[0].x = 3 would be a handy thing  
> to have.  (The clumsy alternative would be to require users to do  
> a[0] = new TA(...);).

It's not a matter of "handy", although WebGL people would agree. If  
the struct is mutable then implementations can't copy it if it has  
reference semantics, and programmers *have to* copy it to avoid  
"behind my back" changes. That's why we seemed to agree last fall (and  
it works for decimal) that value types should be shallowly frozen.

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.

>> -j
>> js-ctypes:
> Thanks for the pointer to js-ctypes! I was unaware of this previously.

Noted on this list previously: 


More information about the es-discuss mailing list