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: https://wiki.mozilla.org/Jsctypes/api
Thanks for the pointer to js-ctypes! I was unaware of this previously.
Noted on this list previously: https://mail.mozilla.org/pipermail/es-discuss/2010-May/011310.html
:-P
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
