Non-extensibility of Typed Arrays

Dmitry Lomov dslomov at
Wed Sep 4 01:23:07 PDT 2013

(sorry for not getting on this thread earlier - I was off the grid for a

I think we should consider fixed-length ArrayTypes in this discussion. They
can be parts of structs.
    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.


On Fri, Aug 30, 2013 at 9:18 PM, Brendan Eich <brendan at> wrote:

> David Herman wrote:
>> >  Typed Arrays are a different beast that already exist in the real
>>> world.  I don't see any need for consistency between Typed Arrays and
>>> struct types. Consistency between Typed Arrays and Array is more important.
>> Mostly agreed, except I'd just refine that to say there's no need for
>> consistency*in this dimension*. It would be a shame if typed arrays weren't
>> generalized by the typed objects API in general, and I worked hard to make
>> the pieces fit together. That nuance aside,
> I think you are too kind :-|.
> Allen, the point about typed arrays being different from structs because
> some implementations make the former extensible and the latter do not exist
> in any implementation yet is a just-so story, half of which is
> hypothetical! I could just as well argue from Firefox's non-extensible
> precedent if I wanted to.
> The better argument is one that accounts for *why* structs are not
> extensible and how typed arrays differ, if they do differ, by design -- not
> based on implementation in some but not all browsers.
>    the fact that, in practice, arrays are patched with additional
>> properties (in fact, IIRC the ES6 template strings API adds properties to
>> arrays) suggests that non-extensibility would be a real incompatibility
>> between arrays and typed arrays.
> This only goes so far, since one could try to argue from objects to
> structs in the same way. What's the difference-in-kind reason? I can give
> answers but I'm looking for others' answers.
>    So I'm cool with making typed arrays -- but not structs -- extensible.
> It's ok if we decide this, but let's have a not-just-so story beyond the
> array-like use-case one -- it's good but without something else, it could
> reason from objects to structs, but no one here wants extensible structs.
> (Right?)
> /be
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at

Google Germany GmbH
*Dienerstr. 12, 80331 München., DE *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list