On Oct 18, 2010, at 3:16 PM, Sam Ruby wrote: > On Mon, Oct 18, 2010 at 6:01 PM, David Herman <dher...@mozilla.com> wrote: >> Are you suggesting a) that struct types should always be value types, or b) >> some sort of extension to the binary data spec that allows the creation of >> immutable structs that are value types? >> >> I'm afraid a) just seems unworkable -- compound binary data needs to be >> mutable, and its sub-components really need to be selectable by reference, >> not by copying. If you meant b) (or something else), can you flesh it out a >> bit more? > > Another possibility is that the current proposal labeled "value-types" > doesn't mention immutability :-)
It does, spelled "frozen": see Value Type means “shallow frozen”. and look for other "frozen" matches in http://wiki.ecmascript.org/doku.php?id=strawman:value_types. > That being said, if the immutability is a pre-requisite for > "value-types" (presumably in order to address the triple equals hard > case), and given that value-types was tossed out there as a potential > solution to the bignum requirement, can somebody sketch out how === > would work for bignums? My intuition is that any triple-equals > solution that works for bignums would also work for decimal. No intuition needed, the page was explicit in paraphrasing Mark's position: ... Mark: no, Value Types mean === can do a recursive, cycle-tolerant structural comparison. Jason: not convinced that complexity is warranted. On es-discuss in the "Structs" thread, Waldemar wrote at https://mail.mozilla.org/pipermail/es-discuss/2010-June/011316.html the following: > b = a[i]; > a[i].x += 1; . . . > 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. > > 2. Recursive value equality: True if and only if all of their constituent > elements are ===. 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). > > 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. But of course the context here includes mutability, since we were talking about WebGL typed arrays, in the same vein as Dave's http://wiki.ecmascript.org/doku.php?id=strawman:binary_data strawman. Mutability is a requirement but === is not. If we separate value types from binary data, where operators including === are required for value types such as bignums, decimal, etc., then we could choose to make value types deeply frozen, and define === as Mark proposed. But Waldemar objected to this because it fails to equate -0 and 0, and it does equate NaN. Still, I believe separating binary data from value types is the right choice. You could use frozen binary data to implement the representation of a value type, whose operators and literal syntax would come from its object-like "clothing" (whether declarative via new syntax or using some Proxy-like API, details TBD). And I believe making value types frozen in some sense is important, for preservation of === and other invariants, and for memoization and sharing of value type instances created via literals. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
