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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
