Non-extensibility of Typed Arrays

Andreas Rossberg rossberg at google.com
Wed Sep 4 03:05:37 PDT 2013


On 4 September 2013 10:23, Dmitry Lomov <dslomov at google.com> 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;
>     a.foo = "foo";
>     s.a = a;
> Assignment to a struct field is a copy, essentially. Of course, s.a[0] is
> now 10. But does s.a.foo 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. Also, it is preferable to make them as lightweight as
possible.

As for other typed arrays, the difference is subtle, and I'd rather go
for consistency.

/Andreas


More information about the es-discuss mailing list