On May 27, 2010, at 3:32 PM, Sam Ruby wrote:
What would the results of the following be:
a[i] === a[i]
Or the following(*):
b=a[i]; ...; b == a[i]
Or the following(*):
a[0]=a[1]; ...; a[0] === a[1]
I hope that the answer is the same in all three cases. If the
answer is the true in all three cases, then this is a value [type]
in the ECMA 334 sense of the word. If the answer is false in all
three cases, then I assert that many will find that to be
surprising, particularly in the first expression.
Good questions.
You're right that if we have value types then structs, even if
schematically defined rather than declared, and used only to optimize
primitive-typed field access, are value types.
In particular, since typed arrays are fixed length but with mutable
elements, a[i] === a[i] implies memoizing when reifying a[i] as an
object. The element structs are not extensible, however -- they're
sealed in ES5 terms. So while you can set a[i].x = ..., you cannot set
a[i].w where no such w was defined in the schema.
b = a[i] just copies the memoized reference to the reified object, so
b == a[i] and of course b === a[i].
a[0] = a[1] could also be made to work with sealed objects reflecting
the struct elements of the arrays. The right-hand side reifies or
finds the memoized object reflecting a[1], the packed struct. The
assignment to a[0] then reads property values from the object (fat
ugly numbers!) and writes into the packed struct at a[0] according to
the schema.
So it still seems to me one could avoid equating value types and these
schema structs. They are distinct proposals, but you could tie them
together. I think that would be a mistake at this point, especially
since WebGL folks have no need for operators and literals (as far as I
know).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
