Sam Ruby rubys at
Fri May 28 13:40:33 PDT 2010

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

More information about the es-discuss mailing list