On 05/27/2010 06:47 PM, Brendan Eich wrote:
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.
... and the value of a[0] === a[1] is?
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).
It is not a matter of whether they "need" === operators to be defined,
but rather a matter of defining what the value of === operators is to be.
Nor, am I suggesting that === be overloadable.
I am suggesting that if a[0]===a[1] is to be true, and one can assume
that a[n] is a series of octets, then we are talking about strncmp like
behavior. And if we can assume strncmp, then I see no reason to
preclude implementations from using strncpy.
/be
- Sam Ruby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss