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

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.

Dmitry



On Fri, Aug 30, 2013 at 9:18 PM, Brendan Eich <brendan at mozilla.com> 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 mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
Google Germany GmbH
*Dienerstr. 12, 80331 München., DE *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130904/1d45bd67/attachment.html>

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

I think we should consider fixed-length ArrayTypes in this discussion. They
can be parts of structs.
Consider

```js
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.