Non-extensibility of Typed Arrays

Filip Pizlo fpizlo at
Wed Sep 4 07:44:25 PDT 2013

> On Sep 4, 2013, at 3:05 AM, Andreas Rossberg <rossberg at> wrote:
>> On 4 September 2013 10:23, Dmitry Lomov <dslomov at> wrote:
>> I think we should consider fixed-length ArrayTypes in this discussion. They
>> can be parts of structs.
>> Consider
>>    var A = new ArrayType(uint8, 10);
>>    var S = new Struct({a : A});
>>    var a = new A();
>>    var s = new S();
>>    a[0] = 10;
>> = "foo";
>>    s.a = a;
>> Assignment to a struct field is a copy, essentially. Of course, s.a[0] is
>> now 10. But does exist? In the current semantics, there is no place
>> to store it, because a field 'a' of struct 'S' is just a storage designator
>> - there is no "place" in struct s to store the expando properties of fields
>> and fields of fields and fields of fields of fields....
>> Therefore in current semantics fixed-length ArrayTypes, just like
>> StructTypes, are either non-expandable, or have to lose their expanded
>> properties on assignments -  big surprise for the user!
>> Now of course variable-sized ArrayTypes do not suffer from this issue, but
>> one could argue for consistency with fixed-sized ArrayTypes.
> I was about to make the same point. :)
> As part of binary data, typed arrays are implicitly constructed "on
> the fly" as views on a backing store. Any notion of identity -- which
> is the prerequisite for state -- is not particularly meaningful in
> this setting.

Are you proposing changing how == and === work for typed arrays?  If not then this whole argument is moot. 

> Also, it is preferable to make them as lightweight as
> possible.

See my previous mail. You gain zero space and zero performance from making typed arrays non extensible. 

> As for other typed arrays, the difference is subtle, and I'd rather go
> for consistency.
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list