Brendan Eich wrote:
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.
Aargh, what fun! This is one of the more fascinating aspects of not having
type annotations.
Possibly the most ECMAScripty approach would be to break the first equivalence
by making the step that converts lvalues to rvalues convert struct references
into copies of structs. In ES5 terms this would be the GetValue internal call.
Struct references would not be first class any more than lvalues are.
Waldemar
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
