On 05/28/2010 01:20 PM, Brendan Eich wrote:
That said, I'm not sure I understand why this should gate anything in
this thread. Value types should be frozen (shallowly immutable)
regardless, or other things break, e.g., they could no longer be
transparently passed by copy. C# got this wrong, and paid a semantic
complexity price we must avoid. Non-frozen structs should not be value
types. Frozen structs could be value types, or could be wrapped in
value types or something.
Agreed. Sam?
There are so many undefined terms in that paragraph that I don't know
what I would be agreeing to.
For example, I don't know why the word "shallowly" was inserted there.
Was that just reflex, or is there an actual requirement to allow object
references inside a struct? Looking at the syntax that Brendan put out
for discussion purposes, it isn't clear to me how one would do that.
const TA =
Array.newTypedArray(fixed_length,
Object.newStructType({x:"u32", y:"u32", z:"u32",
r:"u8", g:"u8", b:"u8", a:"u8"}));
let a = new TA(...);
Mark mentions passed by copy. What happens if I pass a[1] as an
parameter on a method call? Does something semantically different
happen if the struct is frozen vs non-frozen? Is that complexity worth it?
Putting that aside for the moment, my more specific questions is: under
what conditions would it ever be possible for a[1]===a[2] to be true?
There is much wrapped in that simple question. I'm inferring a lot from
the discussion: "typed arrays" have a fixed number of elements, each of
which has a fixed length. It should be possible for implementations to
store entire arrays in contiguous storage.
As such, a[1] and a[2] in a typed array can never be the same object.
Which means that they can never be ===, much less egal. By contrast,
they could conceivably be the same object in a "classic" Array,
depending on how they were constructed.
To facilitate discussion, I toss out the following:
var a = new Array();
a[0] = "a";
a[1] = "ab";
a[0] += "b";
if (a[0] === a[1]) { ... }
To the casual developer, I will assert that the fact that these strings
are treated as being equal is an indication that they have the same
value (i.e., sequence of bits) and not an indication that they occupy
the same storage location (which could conceivably be true, but that's
not generally something the implementation directly exposes).
The real question here: are what is currently being called a struct more
like a bit string with convenient methods of accessing slices, or are
they more like objects where no matter how close the sequence of bits
are, two objects in different locations are never the same.
It might very well be that the requirements are such that the final
conclusion will reluctantly be that it isn't worth trying to make ===
have a sane definition for these structs. That just isn't something I
would expect as a starting position.
- Sam Ruby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
