On Jun 1, 2010, at 6:15 PM, Waldemar Horwat wrote:
b = a[i];
a[i].x += 1;
Now b.x also reflects the new value of a[i].x; i.e. b is an alias,
not a mutable copy. The same thing would happen if one had mutated
b.x.
That leads to a couple plausible meanings of b === a[i]:
1. Pointer equality: True if and only if mutating one's contents
would mutate the other's.
That is a good point. Since WebGL demands a[i] be stored as packed
machine types in-line in a vector of such structs, this is really
asking whether b aliases a[i]. We could make this work.
2. Recursive value equality: True if and only if all of their
constituent elements are ===.
This is what Sam suggested, citing ECMA-334.
I hope that you can't have things like aliases themselves as first-
class values inside structs, as that could create cycles (although
you could still make === work in that case if you really wanted to).
The only types WebGL wants inside structs are machine scalar types,
ints and floats of several sizes. But if we take a broader view, we
could try to define structs that can contain (typed arrays of) (other)
structs, so long as everything bottomed out in primitive types.
The complexity of object-reference-typed struct members does not seem
worth it.
Bit-by-bit equality is not desirable in the presence of NaN's and
signed zeroes. If we go with choice 2, the struct {x:17, y:NaN}
should not be === to {x:17, y:NaN}. Using bit equality, it might or
might not be ===, which then could be used to discriminate among
different kinds of NaN's. There is currently nothing in the
language with that power and I'd prefer to keep it that way.
Ok.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
