brendan at mozilla.com
Thu May 27 15:59:09 PDT 2010
On May 27, 2010, at 3:47 PM, Brendan Eich wrote:
> 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.
Argh, I meant "could be value types." Because I then went on to argue
that sealed objects with writable properties reflecting the element
structs, memoized to avoid a fresh object identity on each a[i], could
be used too.
It pays, especially in the strawman space, to avoid coupling
proposals. But it would be great to have structs of the schematic
kind, and value types with operators and literals (whatever the data
representation, structs or arrays or number pairs), in hand. Then we
could see whether it makes sense to unify.
> 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 = a 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, the packed
> struct. The assignment to a then reads property values from the
> object (fat ugly numbers!) and writes into the packed struct at a
> 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).
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss