Structs

Brendan Eich brendan at mozilla.com
Wed Jun 2 11:14:02 PDT 2010


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



More information about the es-discuss mailing list