should hooks be called with this set to the object they are pulled from?

[bmeck]

new Set([], {
  allowed: [1,2,3],
  coerceValue(v) {
    if (!this.allowed.contains(v)) throw new Error('not allowed');
  }
})

[ljharb]

since you can do:

const self = new Set([], {
  allowed: [1,2,3],
  coerceValue(v) {
    if (!self.allowed.contains(v)) throw new Error('not allowed');
  }
})

already, it doesn't seem to add any capabilities, just avoids some developer pain? (thus, yes)

[rbuckton]

The closest prior-art in the ECMAScript proposal to this are Proxy traps. For proxy traps, this is the handler and the proxy target is provided as an argument. We also pass the collection as an argument for all of the built-in Array, Map, and Set methods that are user-supplied callbacks like map, filter, reduce, forEach, etc.

Having this be the Set/Map and not the options object is inconsistent with the rest of the language.

since you can do [...] already, it doesn't seem to add any capabilities, just avoids some developer pain? (thus, yes)

Your example is incorrect. self doesn't have an allowed property. I think you meant:

const self = {
  allowed: [1,2,3],
  coerceValue(v) {
    if (!self.allowed.contains(v)) throw new Error('not allowed');
  }
};
new Set([], self);

[ljharb]

ohhhh you want it to be the options object. that seems super weird to me.

[rbuckton]

That's what happens for Proxy Handlers:

const handler = {
  get(target, key) {
    console.assert(this === handler);
  }
};
new Proxy({}, handler).x;

[bmeck]

Doing the same as proxy handlers seems fine.

[bmeck]

@rbuckton if mimicking Proxy handlers, should we lookup the functions off the options bag every time like proxies do?

see:

let i = 0;
let o = new Proxy({}, {
  get ["get"]() {
    let n = i++;
    return () => n;
  }
});
console.log(o.x, o.x);
// 0 1

[ljharb]

That seems like it'd create a performance hit :-/

[bmeck]

@ljharb i believe recent proxy optimization passes in some engines do optimize it out once you hit the full compiler. Perhaps an implementer with knowledge of proxy optimizations being done like @MayaLekova might be able to comment if the same optimization would be ok here?

[MayaLekova]

For proxies in V8 we currently do the trap lookup on each call, but we have the idea to eventually use more detailed feedback and speculate that the handler stays the same (and deoptimize if that's not the case). Looks to me that the same optimization can be applied in this collections use-case as well.

Personally I think that being consistent with other similar use-cases (like Proxy handlers) would be the better option.

[bmeck]

this has been updated to align with how Proxy handlers are called and collection moved from this to a parameter, i could not find a place with optional options bag parameter on a glance in the spec that did a Type() check though and so I only tested for the if the options bag was Type() of Object.