On Sep 4, 2013, at 1:00 PM, Niko Matsakis <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
