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