Non-extensibility of Typed Arrays

Filip Pizlo fpizlo at apple.com
Wed Sep 4 10:56:20 PDT 2013



> On Sep 4, 2013, at 9:03 AM, Andreas Rossberg <rossberg at google.com> wrote:
> 
> On 4 September 2013 17:11, Filip Pizlo <fpizlo at apple.com> wrote:
>>>> On Sep 4, 2013, at 7:55 AM, Andreas Rossberg <rossberg at google.com> wrote:
>>>> On 4 September 2013 16:44, Filip Pizlo <fpizlo at apple.com> wrote:
>>>>> On Sep 4, 2013, at 3:05 AM, Andreas Rossberg <rossberg at google.com> wrote:
>>>>> 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.
>>> 
>>> No, they are just rather useless operations on data views. That
>>> doesn't make the argument moot.
>> 
>> The point is that as soon as you're using the copy '=' on binary data
>> fields, you're already losing an observable notion of object identity.  The
>> '=' here is already unlike the '=' operator for languages that have true
>> value types - in those languages you wouldn't be able to observe if you got
>> the *same* typed array or a different one but with the same underlying data.
>> In JS you will be able to observe this with '==' and '==='.  Hence, being
>> able to also observe that you got a different one because you lost some
>> meta-data (i.e. custom named properties) doesn't change the fact that the
>> quirky semantics were already observable to the user.
> 
> I didn't say it's unobservable -- every twist in the gut is observable
> in JavaScript. I said it's rather meaningless. That is, from a
> practical perspective, I'd rather not recommend relying on it, unless
> you are up for subtle and brittle code.

Are you saying that users shouldn't rely on == on objects?  My concern here is that binary data, which is a rather obscure addition to the language, doesn't break mainstream uses of the language. Disallowing custom properties on typed array objects just because binary data assignments lose object identity is silly. You're already losing object identity and it's already observable. Custom properties have nothing to do with this. 

-F

> 
> 
>> As far as I can tell, this object model compresses typed arrays about as
>> much as they could be compressed while also allowing them to be extensible.
>> The downside is that you pay a small penalty for typed arrays that have an
>> "active" buffer, in the case that you either accessed the .buffer property
>> or you constructed the typed array using a constructor that takes a buffer
>> as an argument.
> 
> I really don't feel like getting into this argument -- as I said it's
> a minor point. Just note that the optimisation you suggest might not
> be worth it in every VM (i.e., there could be a substantial impedance
> mismatch), and moreover, that the above case might be not-so-uncommon.
> 
> /Andreas


More information about the es-discuss mailing list