Non-extensibility of Typed Arrays

Niko Matsakis niko at alum.mit.edu
Wed Sep 4 13:00:03 PDT 2013


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.

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).

[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.]


Niko


More information about the es-discuss mailing list