Non-extensibility of Typed Arrays

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Aug 30 09:39:58 PDT 2013


On Aug 30, 2013, at 8:53 AM, Mark S. Miller wrote:

> Dave Herman's "And the other consistency dimension is between array types and struct types. Is anyone arguing that structs should also have expandos?" surprised me, and convinced me of the opposite conclusion. Do you think instances of struct types should be extensible?

I think the right-way to think about structs is as an record structure with no properties fixed behavior provided by a "wrapper".  Very similar to the ES primitives except that structs can be mutable.  The way to associate properties with structs is to encapsulate them in an object, preferably via a class definition. If we go that route we can reach the point where ES classes have fixed-shape internal state defined as-if by a struct.

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.

Allen







> 
> 
> On Fri, Aug 30, 2013 at 8:48 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> This thread has convinced my that Typed Arrays should be born extensible. 
> 
> Actually, my subclass example in the thread started me down that path.  In many cases where you might subclass an array you will want to add per instance state.  You can expose a getter/setter on the prototype but the state still needs to be associated with the individual instances.  Expando properties (or even better properties added in the @@create method) are the most natural way to represent that state.
> 
> The Firefox implementors will make this change if it represents TC39 consensus.
> 
> I'll put this item on the agenda for the next meeting and see if we can agree on extensible Typed Arrays.
> 
> Allen
> 
> 
> 
> 
> On Aug 28, 2013, at 11:01 PM, Filip Pizlo wrote:
> 
>> Here's the part that gets me, though: what is the value of disallowing named properties on typed arrays?  Who does this help?
>> 
>> I don't quite buy that this helps users; most of the objects in your program are going to allow custom properties to be added at any point.  That's kind of the whole point of programming in a dynamic language.  So having one type where it's disallowed doesn't help to clarify thinking.
>> 
>> I also don't buy that it makes anything more efficient.  We only incur overhead from named properties if you actually add named properties to a typed array, and in that case we incur roughly the overhead you'd expect (those named properties are a touch slower than named properties on normal objects, and you obviously need to allocate some extra space to store those named properties).
>> 
>> -Filip
>> 
>> 
>> 
>> On Aug 28, 2013, at 10:52 PM, Steve Fink <sphink at gmail.com> wrote:
>> 
>>> On 08/27/2013 09:35 AM, Oliver Hunt wrote:
>>>> My complaint is that this appears to be removing functionality that has been present in the majority of shipping TA implementations, assuming from LH's comment that Chakra supports expandos.
>>> 
>>> Note that even in the engines that support expandos, they will probably
>>> not survive a structured clone. I just tried in Chrome and they get
>>> stripped off. This further limits their utility in today's Web.
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130830/57c61ba7/attachment.html>


More information about the es-discuss mailing list