Re: Re: Proxy handler.has() does not have a receiver argument?

I forgot to add, this even works with builtin scenarios like Custom Elements, ```js class MyEl extends mix(HTMLButtonElement, One, Two, Three) { /* ... */ } customElements.define('my-el', MyEl) ``` On Fri, Nov 22, 2019 at 9:36 AM #!/JoePea wrote: > HI Cyril, thanks for pointing that out! I

Re: Re: Proxy handler.has() does not have a receiver argument?

HI Cyril, thanks for pointing that out! I know about those, I've been using class-factory mixins for a while now. But the problem with them is having to wrap all your classes in a function, which gets much more painful in TypeScript with all the type-annotation boilerplate that is required. For

Re: Re: Proxy handler.has() does not have a receiver argument?

It's not answering your issue with Proxy but more about multiple inheritance It can be solved in a static way: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#Mix-ins Concrete example here: https://github.com/pepabo/gmopg/blob/master/src/gmopg.ts#L10 On Fri, Nov 22,

Re: Re: Proxy handler.has() does not have a receiver argument?

After messing with Proxy-on-prototypes for two days, I've just come to the conclusion that I probably need to have Proxies on this (the receiver) returned from constructors to achieve what I want. At least, it's much easier to code it that way. I think it'd be nice to have receiver on all

Re: Re: Proxy handler.has() does not have a receiver argument?

I really thing that because `has` is about detecting inherited properties, the `receiver` parameter should be included. For things like `ownKeys`, which are not about inheritance, then yeah, let's not add receiver there. I'm trying to implement my own multiple inheritance, but now I stumbled on

Re: Proxy handler.has() does not have a receiver argument?

That is good news then. I think I have the right expectations of proxies now. Sharing one handler is easy too. All you need to do is map both the `proxy` and its `target` to the same data. `receiver` is actually the proxy but the argument is no longer important here. ```js var priv = new

Re: Proxy handler.has() does not have a receiver argument?

> On Mar 18, 2016, at 9:24 AM, Andrea Giammarchi > wrote: > > Agreed with everybody else the `receiver` is always needed and `Proxy` on the > prototype makes way more sense than per instance. I don’t agree. While you certainly can imagine a language where each

Proxy handler.has() does not have a receiver argument?

I feel like it should, or I am misunderstanding something fundamental. I made a basic scenario to explain: ```js var arrays = new WeakMap(); function ArrayView(array) { arrays.set(this, array); return new Proxy(this, { set: (target, property, value) => (arrays.has(this) && property in

Re: Proxy handler.has() does not have a receiver argument?

I'm trying to make the proxy-as-a-prototype pattern work but I've just discovered the `ownKeys` trap is never called on traps on the prototype. So even if the `has` trap is allowed to see the `receiver`, and thus verify the properties "0", "1" exist, this pattern would fail to return the

Re: Proxy handler.has() does not have a receiver argument?

AFAIK the reason there is a `receiver` is to deal with prototype cases ... if that was a good enough reason to have one, every prototype case should be considered for consistency sake. We've been advocating prototypal inheritance for 20 years and now it's an obstacle or "not how JS is"? ```js

Re: Proxy handler.has() does not have a receiver argument?

I agree with Allen. I am certainly willing -- often eager -- to revisit and revise old design decisions that are considered done, when I think the cost of leaving it alone exceeds the cost of changing it. In this case, the arguments that this extra parameter would be an improvement seem weak. Even

Re: Proxy handler.has() does not have a receiver argument?

2016-03-19 0:15 GMT+01:00 Michael Theriot : > To be clear, I'm not suggesting behavior like `getOwnPropertyNames` be > overridden by anything on the prototype, just a way to use proxies without > having to instantiate identical copies that all use the same handler.

Re: Proxy handler.has() does not have a receiver argument?

> > Michael’s preferred approach also introduces observable irregularity into > the standard JS inheritance model for ordinary objects. > Consider an object created using Michael’s preferred approach: > ```js > var arr = [0, 1]; > console.log(Reflect.has(arr,”0”)); //true, arr has “0” as an own

Re: Proxy handler.has() does not have a receiver argument?

Agreed with everybody else the `receiver` is always needed and `Proxy` on the prototype makes way more sense than per instance. Also the `getPrototypeOf` trap is really pointless right now ```js function Yak() {} Yak.prototype = new Proxy(Yak.prototype, { getPrototypeOf: (target) =>

Re: Proxy handler.has() does not have a receiver argument?

To be clear, I'm not suggesting behavior like `getOwnPropertyNames` be overridden by anything on the prototype, just a way to use proxies without having to instantiate identical copies that all use the same handler. I still believe a proxy on the prototype should always have a `receiver` sent to

Re: Proxy handler.has() does not have a receiver argument?

I think I figured out how to make inheritance work... ```js var wm1 = new WeakMap(); function A() { let proxy = new Proxy(this, { get: (target, property, receiver) => property === 'bacon' || target[property] }); wm1.set(proxy, {}); return proxy; } var wm2 = new WeakMap(); function B() { let proxy