On May 27, 2010, at 5:21 PM, Sam Ruby wrote:
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?
With any kind of mutable object reflecting the packed struct, the
answer will be false unless we have value types. See
http://wiki.ecmascript.org/doku.php?id=strawman:value_types#hard_cases
search for ===.
Value types were conceived of as shallowly frozen, but we could try to
relax that.
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.
If you want this, whether === is overloadable, and WebGL (lots of
folks, let's say) want structs in the array to be mutable, then we run
into the conflict recorded in the wiki.
''Jason: === must be overloadable. Mark: no, Value Types mean === can
do a recursive, cycle-tolerant structural comparison. Jason: not
convinced that complexity is warranted.
...
Decision logic:
if (=== is overloadable) {
The need for egal goes up;
if (egal is added (it is not overloadable))
{0, -0} and NaN issues go away;
} else {
The need for egal goes down,
because === is well-defined as structural recursive etc. comparison;
}
Value Type means “shallow frozen”.''
Say we add egal, so one can tell the difference between a[0] and a[1]
even if they happen to contain the same bits, because that difference
might matter due to one of them being mutated to have different bits.
Then do the objections to unfrozen value types go away? Cc'ing Mark.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss