Non-extensibility of Typed Arrays

Filip Pizlo fpizlo at apple.com
Wed Sep 4 13:08:29 PDT 2013


On Sep 4, 2013, at 1:00 PM, Niko Matsakis <niko at alum.mit.edu> wrote:

> On Wed, Sep 04, 2013 at 12:38:39PM -0700, Filip Pizlo wrote:
>> The reason why I'm OK with the more complex story is that we already
>> have that story for '=='.  To me, named object properties are
>> analogous to being able to identify whether you have the same object
>> or a different object: both are mechanisms that reveal aliasing to
>> the user.  Having typed objects that are embedded in other ones
>> already breaks ==.
> 
> I'm afraid I don't quite follow you here. The point is not that
> extensible properties permit the user to observe aliasing: since
> arrays are mutable, aliasing is observable even without `==` or
> extensible properties.

Ah, sorry, I was unclear.  My point is that given two typed arrays a and b, both == and custom properties allow you to tell the difference between a and b sharing the same backing data (the kind of aliasing you speak of) and actually being the same object.

== allows you to do this because either a == b evaluates true or it evaluates false.  If you allocate a typed array 'a' and then store it into a binary data field and then load from that field later into a variable 'b', then a != b.  Hence, you've observed that a and b don't point to the same object.

Likewise, custom named properties would also allow you to make the same observation.  If you allocate a typed array 'a', then store a custom field into it ('a.foo = 42'), then store it into a binary data field and later load from it into 'b', then 'b.foo != 42'.  Hence, again, you've observed that a and b don't point to the same object even though they are both wrappers for the same underlying array data.

I agree that both of these aspects of binary data are quirky.  My observation is that prohibiting custom properties doesn't fix the underlying issue.

> 
> Rather, I am saying that it seems desirable for all typed objects with
> a particular type to support the same set of operations: but this is
> not possible if we permit extensible properties on typed arrays, since
> there will always be a distinction between a "top-level" array (i.e.,
> one that owns its own memory) and a derived array (one that aliases
> another object).

Right but that distinction is already there for ==.

> 
> [Well, I suppose it would be possible to permit *all* array instances
> to have extensible properties, whether they are derived or not, but
> that seems surprising indeed. It would imply that if you did
> something like:
> 
>     var MyArray = new ArrayType(...);
>     var MyStruct = new ArrayType({f: MyArray});
>     var struct = new MyStruct(...);
>     var array1 = struct.f;
>     var array2 = struct.f;
> 
> then `array1` and `array2` would have disjoint sets of extensible
> properties.]

Yes, they would.  But even if they didn't, then array1 != array2, which is equally odd.

-Filip


> 
> 
> Niko

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


More information about the es-discuss mailing list