On 05/27/2010 05:29 PM, Brendan Eich wrote:
On May 27, 2010, at 2:18 PM, Jonas Sicking wrote:
On Thu, May 27, 2010 at 12:05 PM, Brendan Eich <[email protected]>
wrote:
If structs are anything like value types, then I am interested in
participating. I'm particularly interested in working through the
details
of how arithmetic of integer like quantities would work.
The struct-array idea for WebGL avoids the typed array aliasing
design, and
consequent byte-order leakage. But we are not envisioning new operator
overloading or literal syntax. At most a[i].x would be optimized to a
very
fast, packed member read or write, after scaling i and adding the
offset of
x. Any read would use ES's number type, I believe.
The other thing that Khronos really wanted to avoid was for a[i] in
the above expression not to create an object which is to be
initialized and GCed. Though maybe you're including that in the
scaling+offset algorithm.
Yes, I wrote a[i].x on purpose. Just a[i] with no .x or .y, etc. after
would reify a JS object.
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 time 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.
- Sam Ruby
(*) where "..." is a series of statements that do not affect the value
of b or a.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
