Integer indexed exotic object [[Set]] can not ignore receiver

[evilpie]

The change from #347 is not web compatible. I implemented the new behavior of ignoring the receiver in [[Set]] in Firefox and this turns out to be not web-compatible. No other browser seems to have implemented this behavior, probably because there is no test262 test for it.

A reduced example that fails with this change:

function Vec3(x, y, z) {
  this[0] = x;
  this[1] = y;
  this[2] = z;
}

Vec3.prototype = new Float32Array(3);

Vec3.prototype.set = function(x, y, z) {
  this[0] = x;
  this[1] = y;
  this[2] = z;
}

var vec = new Vec3(1, 2, 3);
var vec2 = new Vec3(4, 5, 6);
console.log(vec[0], vec[1], vec[2]) // 4, 5, 6 (shared prototype changed)

[littledan]

cc @verwaest

[verwaest-zz]

I think my intention for [[set]] didn't come across exactly since I focused on [[get]]. My intention was that typed arrays would always block keys not in the typed array range from being set on the receiver, independent of where they occur on the prototype chain. The intention was not to update the array values in the typed array on the prototype chain. Hence: o = {__proto__: new Int32Array(1) }; o[0] = 1; o[0] == 1; // true o.__proto__[0] == 1; // false o[1] = 1; o[1] == 1; // false That's what V8 has been shipping since after that issue was filed.

…

On Mon, Oct 29, 2018 at 9:11 PM Daniel Ehrenberg ***@***.***> wrote: cc @verwaest <https://github.com/verwaest> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1339 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASgHhlIiPPkKjLwbzgiHu6DCoDomLgxks5up2DngaJpZM4YAGDC> .

[evilpie]

@verwaest That behaviour you suggest seems to be web-compatible, or at leas it would not break my example that is based on real world breakage. However it's not super obvious to me why this is useful behaviour, is this just an incremental step because we can't totally restrict it like the spec suggest or is there some advantage to that approach that I am missing?

[littledan]

Would anyone be interested in writing a PR which documents the web reality semantics? (Are they common between JS implementations? Mostly common?) Concreteness about what there is right now could help us understand what makes sense to adopt.