Re: Why does a JavaScript class getter for a private field fail using a Proxy?

` >> >> I think there is something missing from that example as that line >> throws before it can get to the `new Proxy` line. >> >> #!/JoePea >> >> On Wed, Jul 15, 2020 at 10:47 PM Jordan Harband wrote: >> > >> > So can: >> > ``

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

oh oops, i meant `if (o !== this)` not `if (o.foo !== this)` :-) On Mon, Jul 27, 2020 at 3:06 PM #!/JoePea wrote: > > `o.foo(); // works` > > I think there is something missing from that example as that line > throws before it can get to the `new Proxy` line. > > #!/JoeP

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

> `o.foo(); // works` I think there is something missing from that example as that line throws before it can get to the `new Proxy` line. #!/JoePea On Wed, Jul 15, 2020 at 10:47 PM Jordan Harband wrote: > > So can: > ```jsx > const o = { foo() { if (o.foo !== this) {

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

So can: ```jsx const o = { foo() { if (o.foo !== this) { throw 'detected'; } } }; o.foo(); // works new Proxy(o, {}).foo(); // throws ``` (as would a class that used a closed-over WeakMap for each "private field") Private fields do not introduce any new hazards here. On Tue, Jul 14,

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

timately want >> achieved? >> >> ```js >> const sub = new Sub() >> >> // i'm a noob on proxies. what is this thing (with proxied-private-fields) >> ultimately used for? >> const proxy = new Proxy(sub, ...) >> ``` >> >> On Sun, Jul

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

eaking privacy. TC39 did not choose in favor of privacy, they chose to leave a feature out and make private fields less private than they should be. > With that being said workarounds have already been presented: Those workaround only work in certain cases, namely when you control the proxy and

RE: Why does a JavaScript class getter for a private field fail using a Proxy?

To quote from a short conversation I had with Allen Wirfs-Brock: “Proxies have a similar issue WRT the "internal slots" of built-ins. The alternatives were the non-othogonality with Proxy or private fields whose privacy was insecure. TC39 choose (correctly, I think) in favor of se

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

you ultimately want > achieved? > > ```js > const sub = new Sub() > > // i'm a noob on proxies. what is this thing (with proxied-private-fields) > ultimately used for? > const proxy = new Proxy(sub, ...) > ``` > > On Sun, Jul 12, 2020 at 4:34 PM Michael Theriot <

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

as product-developer, can i ask what ux-objective you ultimately want achieved? ```js const sub = new Sub() // i'm a noob on proxies. what is this thing (with proxied-private-fields) ultimately used for? const proxy = new Proxy(sub, ...) ``` On Sun, Jul 12, 2020 at 4:34 PM Michael Theriot

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

iv); >> >> } >> >> >> >> get hidden() { >> >> const priv = stores.get(this[privkey]); >> >> return priv.hidden; >> >> } >> >> } >> >> >> >> var as = [ >> >> new

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

constructor() { > > const priv = {}; > > priv.hidden = Math.random(); > > stores.set(this[privkey], priv); > > } > > > > get hidden() { > > const priv = stores.get(this[privkey]); > > return priv.hidden; > > } > > } >

RE: Why does a JavaScript class getter for a private field fail using a Proxy?

(this[privkey]); return priv.hidden; } } var as = [ new A(), new Proxy(new A(),{}), new Proxy(new A(),{}), ]; console.log(as.map(a=>a.hidden)); ``` From: Michael Theriot<mailto:michael.lee.ther...@gmail.com> Sent: Sunday, July 12, 2

Re: Why does a JavaScript class getter for a private field fail using a Proxy?

priv.hidden; } } const a = new A(); console.log(a.hidden); // 0 const p = new Proxy(a, {}); console.log(p.hidden); // throws! ``` I found a workaround: ```js const stores = new WeakMap(); class A { constructor() { const priv = {}; priv.hidden = 0; stores.set(this, priv); const p

RE: Why does a JavaScript class getter for a private field fail using a Proxy?

This is a known issue and very painful for me as well. You can see a long ugly discussion here: <https://github.com/tc39/proposal-class-fields/issues/106> I suggest the following guide to assist you: <https://javascript.info/proxy#proxy-limitations> Another possible approach is

Why does a JavaScript class getter for a private field fail using a Proxy?

I can expose private class fields in JavaScript using getters, and those getters work correctly when invoked on instances of a subclass. However, if I then wrap the instance with a proxy the getter will throw a type error, even if the proxy `get` hook uses `Reflect.get()`: ``` class Base

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

inheritance with Proxies actually turns out very easy to type in > TypeScript, and a lot more convenient than class factories. So, given a set > of regular classes, > > ```js > class One { > doOne() { /* ... */ } > } > > class Two { > doTwo() { /* ... */ } &g

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

turns out very easy to type in TypeScript, and a lot more convenient than class factories. So, given a set of regular classes, ```js class One { doOne() { /* ... */ } } class Two { doTwo() { /* ... */ } } class Three { doThree() { /* ... */ } } ``` a Proxy-based multiple inheritance system

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: Proxy Reflect.has() call causes infinite recursion? (#!/JoePea)

Any idea why it isn't spamming the console? I mean, if it is recursive, shouldn't it fire my console.logs over and over, like 50,000 times, before finally throwing the error? On Thu, Nov 21, 2019 at 3:12 PM Alex Vincent wrote: > > I'm afraid your testcase is still far too complicated to really

Re: Proxy Reflect.has() call causes infinite recursion? (#!/JoePea)

I'm afraid your testcase is still far too complicated to really figure out at first glance. It looks like you're trying to implement a mixin pattern. In my experience, it's better to implement the getPrototypeOf, getOwnPropertyDescriptor, and defineProperty traps, and maybe make your get, set,

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 Reflect.has() call causes infinite recursion?

gt; What's going on? > > Here's the code for reference, see "PROXY INFINITE RECURSION" comments > for the site where the problem is happening (as far as I can tell in > devtools): > > ```js > "use strict"; > > function multiple(...classes) {

Proxy Reflect.has() call causes infinite recursion?

expect, so it seems that the infinite recursion is happening inside the JS engine? What's going on? Here's the code for reference, see "PROXY INFINITE RECURSION" comments for the site where the problem is happening (as far as I can tell in devtools): ```js "use strict";

Re: Proxy target/handler access leak in Node

he impression that the util.inspect.custom symbol or the functionality it provides is itself problematic. It just happens to be possible to use it, currently, to get inside the proxy target/handler because its second argument is an object with a property whose value is a function that can be call

Re: Proxy target/handler access leak in Node

> The Node.js trust model assumes that all code is trusted. First I want to respond to this sentence out of context. I often hear such phrases. I know what people mean by this, but the phrase "trusted" here *always* leads to confusion and muddy thinking. I don't trust the code I wrote yesterday.

Re: Proxy target/handler access leak in Node

On Mon, Sep 17, 2018 at 8:32 AM Darien Valentine wrote: > Thanks for the context, James. Yes, this thread mainly concerns the issue > of being able to obtain references to values within the handler/target from > external code, though I did try to make a case for not having the showProxy > option

Re: Proxy target/handler access leak in Node

dress a user issue where inspection of a Proxy object (that the > user didn't know was a proxy object) would cause an infinite loop when > invoking a certain getter that just happened to have a console.log > statement (in Node.js, console.log uses util.inspect in some cases. There >

Re: Proxy target/handler access leak in Node

Some background as I am the one who added the showProxy feature into Node.js... util.inspect() is considered by Node.js to be a diagnostics API. The intent is to allow adequate debugging in a variety of scenarios. This was added to address a user issue where inspection of a Proxy object

Re: Proxy target/handler access leak in Node

.) - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Sun, Sep 16, 2018 at 9:19 PM Darien Valentine wrote: > > > What is going on here? Can you explain? > > A C++/V8 API is used to obtain references to the target and handler from only > the proxy object, even th

Re: Proxy target/handler access leak in Node

> What is going on here? Can you explain? A C++/V8 API is used to obtain references to the target and handler from only the proxy object, even though those objects aren’t supposed to be available to this ES scope: https://github.com/nodejs/node/blob/master/lib/util.js#L642-L647 The p

Re: Proxy target/handler access leak in Node

concerns an opinion >> that proxies should not be treated as special case, I included an example >> of a mechanism by which the current implementation allows outside code to >> access the target and handler objects of a proxy that it does not own. >> >> On reflection

Re: Proxy target/handler access leak in Node

ncerns an opinion > that proxies should not be treated as special case, I included an example > of a mechanism by which the current implementation allows outside code to > access the target and handler objects of a proxy that it does not own. > > On reflection I realized this specific

Proxy target/handler access leak in Node

the target and handler objects of a proxy that it does not own. On reflection I realized this specific issue might be worth drawing more attention to. ```js const util = require('util'); const victim = new Proxy({}, { SECRET: 'Nothing outside can access this' }); let secret; const

Re: An idea to extend the functionality of Proxy objects.

The problem is enforcing the invariants. For example, if [[GetOwnProperty]] returns a non-configurable non-writable descriptor, then all future calls must also return a non-configurable non-writable descriptor with the same value. But you can't check this by just calling some traps. Instead,

Fwd: An idea to extend the functionality of Proxy objects.

-- Forwarded message -- From: Ranando King <king...@gmail.com> Date: Sat, Jan 13, 2018 at 2:35 PM Subject: Re: An idea to extend the functionality of Proxy objects. To: Isiah Meadows <isiahmead...@gmail.com> Sorry clicked send before editing. The first version is

Fwd: An idea to extend the functionality of Proxy objects.

-- Forwarded message -- From: Ranando King <king...@gmail.com> Date: Mon, Jan 15, 2018 at 12:34 AM Subject: Re: An idea to extend the functionality of Proxy objects. To: Isiah Meadows <isiahmead...@gmail.com> I'm only including the altered verbiage for each int

Fwd: An idea to extend the functionality of Proxy objects.

-- Forwarded message -- From: Ranando King <king...@gmail.com> Date: Sat, Jan 13, 2018 at 2:32 PM Subject: Re: An idea to extend the functionality of Proxy objects. To: Isiah Meadows <isiahmead...@gmail.com> After thinking about it a bit more, maybe you mean so

Fwd: An idea to extend the functionality of Proxy objects.

-- Forwarded message -- From: Ranando King <king...@gmail.com> Date: Sat, Jan 13, 2018 at 2:23 PM Subject: Re: An idea to extend the functionality of Proxy objects. To: Isiah Meadows <isiahmead...@gmail.com> While I understand what you're getting at, The inva

Fwd: An idea to extend the functionality of Proxy objects.

-- Forwarded message -- From: Isiah Meadows <isiahmead...@gmail.com> Date: Fri, Jan 12, 2018 at 9:07 PM Subject: Re: An idea to extend the functionality of Proxy objects. To: Ranando King <king...@gmail.com> Not full, but changes of some kind will likely be requi

Fwd: An idea to extend the functionality of Proxy objects.

-- Forwarded message -- From: Ranando King <king...@gmail.com> Date: Fri, Jan 12, 2018 at 7:41 PM Subject: Re: An idea to extend the functionality of Proxy objects. To: Isiah Meadows <isiahmead...@gmail.com> You're right about the mistake with Object.seal. I wasn't

Re: An idea to extend the functionality of Proxy objects.

i, Jan 12, 2018 at 5:38 PM, Ranando King <king...@gmail.com> wrote: > > I have an idea I’d like to propose with regards to Proxy objects. I would > > like to make a change to spec section 6.1.7.3 (as seen in the latest > draft). > > The change is as follows: > > > >

Re: An idea to extend the functionality of Proxy objects.

-internal-methods - Isiah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Fri, Jan 12, 2018 at 5:38 PM, Ranando King <king...@gmail.com> wrote: > I have an idea I’d like to propose with regards

An idea to extend the functionality of Proxy objects.

I have an idea I’d like to propose with regards to Proxy objects. I would like to make a change to spec section 6.1.7.3 (as seen in the latest draft). The change is as follows: The Internal Methods of Objects of an ECMAScript engine must conform to the list of invariants specified below. Ordinary

Re: Suggestion: Proxy.[[GetOwnProperty]] caching non-configurable, non-writable data descriptors?

> -- Forwarded message -- > From: Oriol _ <oriol-bugzi...@hotmail.com> > Instead of storing the properties in a map, I think you could first call > [[GetOwnProperty]] on the target, and if it's not configurable nor > writable, return the same descriptor with

Re: Suggestion: Proxy.[[GetOwnProperty]] caching non-configurable, non-writable data descriptors?

signed with the idea that the handler could also be a Proxy, that’s why we do all the gymnastics in the spec. V8 has started some effort to improve proxies: https://v8project.blogspot.com/2017/10/optimizing-proxies.html <https://v8project.blogspot.com/2017/10/optimizing-proxies.html> My suggestio

Re: Suggestion: Proxy.[[GetOwnProperty]] caching non-configurable, non-writable data descriptors?

Instead of storing the properties in a map, I think you could first call [[GetOwnProperty]] on the target, and if it's not configurable nor writable, return the same descriptor without calling the proxy trap. However, I disagree with this kind of things. Proxy traps are not only useful because

Suggestion: Proxy.[[GetOwnProperty]] caching non-configurable, non-writable data descriptors?

, indirectly calling ValidateAndApplyPropertyDescriptor for this case. 6. The [[Get]] or [[Set]] internal methods is probably executing, calling [[GetOwnProperty]] or [[DefineOwnProperty]] for this case. That is a very specific set of traits. As I understand it, it means the proxy target's

Re: Native Proxy Syntax

Inline... On Wed, Aug 23, 2017 at 11:08 AM Vihan Bhargava <cont...@vihan.org> wrote: > The `Proxy` class is great for classes however at the moment, the current > syntax can be unwieldy: > > ``` > class MyClass { >constructor() { >return new Proxy(this, {

RE: Native Proxy Syntax

ing to determine property } constructor() { return new Proxy(this, {get}); } } ``` While this does require an extra return statement it's reasonably tidy and has the huge benefit of providing private variables in a class (as local variables in a closure). But I have to beli

Re: Native Proxy Syntax

I feel like this would be easier handled as a subclass helper: ``` f ​unction asProxy(traps={}, Class=function asProxy(){}) { return class extends Class { constructor() { super(...arguments); return new Proxy(this, traps); } } }​ class MyClass extends asProxy

Native Proxy Syntax

The `Proxy` class is great for classes however at the moment, the current syntax can be unwieldy: ``` class MyClass { constructor() { return new Proxy(this, { get: function(target, name) { if (name in target) return target[name]; // ... do

Re: Proxy performance: JIT-compilation?

> On Aug 8, 2017, at 5:03 PM, Mark Miller wrote: > > So from y'all's various implementation perspectives, how does > https://github.com/tvcutsem/es-lab/issues/21 > look? Do you think it would > make it easier to achieve much

Re: Proxy performance: JIT-compilation?

Tue, Aug 8, 2017 at 3:32 PM, Isiah Meadows <isiahmead...@gmail.com> wrote: > Yes, it's possible to optimize them using specialized ICs on the proxy > handler itself, but it would be *far* easier to optimize it if the ICs > weren't necessary in the first place, since you can just build i

Re: Proxy performance: JIT-compilation?

Yes, it's possible to optimize them using specialized ICs on the proxy handler itself, but it would be *far* easier to optimize it if the ICs weren't necessary in the first place, since you can just build it into the proxy's type, almost like a lazily-generated vtable. It's just far less work than

Re: Proxy performance: JIT-compilation?

oposal) for a subtle change to proxy semantics that > * should break essentially no current code, > * repair the cycle detection transparency violation bug, > * enable many proxies to be *much* faster. > > > I actually don’t see why any semantic changes are needed to enable

Re: Proxy performance: JIT-compilation?

of course Proxy is going to cause deoptimization problems when you start breaking assumptions about Object builtins (which obviously have more aggressive and specialized optimizations than generic methods). in v8, i understand the common-case optimization for builtin getters to be a direct

Re: Proxy performance: JIT-compilation?

Alex, I'll just point out that you are already engaged in the best kind of activity to get implementors to optimize these paths: Building a membrane library that can get widespread use, which encapsulate the complexity of proxies behind a more usable API, for which these proxy operations

Re: Proxy performance: JIT-compilation?

So, how many boxes of chocolates do I need to send to the two big vendors in Mountain View? :-) It's been fifteen years since I seriously tried to profile C++ code, and I didn't really know what I was doing back then: unfamiliar tools, and less competence in C++ than I would've liked. What

Re: Proxy performance: JIT-compilation?

oposal) for a subtle change to proxy > semantics that > * should break essentially no current code, > * repair the cycle detection transparency violation bug, > * enable many proxies to be *much* faster. > > > I actually don’t see why any semantic changes are needed to ena

Proxy performance: JIT-compilation?

re. Proxies are one of the frontiers of JavaScript, largely unexplored. The ECMAScript specification makes no mention whatsoever of just-in-time compilation (rightly so, I would think). But this means that proxy code execution might be one of those areas where we do not currently enjoy the benef

Re: Proxy

ergonomic than proxies for that in my experience, > although I generally make no distinction regarding `this` (which only > complicates in this area). > > On Wed, Dec 14, 2016, 20:47 Uther Pendragon <uther...@gmail.com> wrote: > >> Perhaps it's a bit late... but I'd like to

Re: Proxy

her...@gmail.com> wrote: > Perhaps it's a bit late... but I'd like to discuss the proxy object. > Notably: why no way to define a hook for when a property is called as a > function. > > I think I understand *why* there isn't one.. I presume because how a > property is used (I.e.

Re: Proxy

On 15 December 2016 at 03:26, Boris Zbarsky wrote: > I presume most implementations define scope >> variables much like object properties internally. >> > > That's not clear to me at all. In general, non-object environments don't > need to support all the operations objects do

Re: Proxy

On 12/14/16 8:47 PM, Uther Pendragon wrote: Perhaps it's a bit late... but I'd like to discuss the proxy object. Notably: why no way to define a hook for when a property is called as a function. See thread at <https://esdiscuss.org/topic/es6-proxy-function-call-trap>. I think I unde

Proxy

Perhaps it's a bit late... but I'd like to discuss the proxy object. Notably: why no way to define a hook for when a property is called as a function. I think I understand *why* there isn't one.. I presume because how a property is used (I.e. as a property or called as a function) is a level

Re: Proposal: Proxy iteration (`let ... of ...`) trap handler

4 PM, Tycho Grouwstra <tychogrouws...@gmail.com > <javascript:_e(%7B%7D,'cvml','tychogrouws...@gmail.com');>> wrote: > > Thank you. > > To elaborate a bit, what I'm trying to do is use Proxy so as to enable > FSM-like DSLs, essentially having one Proxy type represent the

Re: Proposal: Proxy iteration (`let ... of ...`) trap handler

It seems like Jordan's suggestion is what you want then. - Saam > On Sep 24, 2016, at 9:54 PM, Tycho Grouwstra <tychogrouws...@gmail.com> wrote: > > Thank you. > > To elaborate a bit, what I'm trying to do is use Proxy so as to enable > FSM-like DSLs, essential

Re: Proposal: Proxy iteration (`let ... of ...`) trap handler

Thank you. To elaborate a bit, what I'm trying to do is use Proxy so as to enable FSM-like DSLs, essentially having one Proxy type represent the current 'state' dictating what DSL you're in, one property access choosing to either yield a new proxied object, yielding an unwrapped version, or one

Re: Proposal: Proxy iteration (`let ... of ...`) trap handler

The purpose of the iterator protocol is to be flexible and to work well with custom defined iterators. for...of is more or less sugar around the iterator protocol. Not sure why you even need a Proxy to easily customize for...of behavior for arbitrary objects. More documentation on the protocol

Re: Proposal: Proxy iteration (`let ... of ...`) trap handler

Does a trap for `[[Get]]` on `Symbol.iterator` not provide you the ability to intercept iteration by returning a custom function? On Sat, Sep 24, 2016 at 8:34 PM, Tycho Grouwstra <tychogrouws...@gmail.com> wrote: > I'd like to propose adding support for an iteration trap handler fo

Proposal: Proxy iteration (`let ... of ...`) trap handler

I'd like to propose adding support for an iteration trap handler for Proxy, fleshing out the list of [currently supported Proxy handlers]( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy#Methods_of_the_handler_object ). I think Proxy is among the most

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 WeakMap

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

> On Mar 18, 2016, at 9:24 AM, Andrea Giammarchi <andrea.giammar...@gmail.com> > 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

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) &&am

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

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

t;? ```js class Magic extends new Proxy(unbe, lievable) { // please make it happen // as it is now, that won't work at all } ``` Best Regards On Fri, Mar 18, 2016 at 7:30 PM, Mark S. Miller <erig...@google.com> wrote: > I agree with Allen. I am certainly willing -- often eager -- to r

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

. On Fri, Mar 18, 2016 at 12:17 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > On Mar 18, 2016, at 9:24 AM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > > Agreed with everybody else the `receiver` is always needed and `Proxy` on > the prototype

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

he same handler. > If you can already reuse the same handler object between multiple proxies, you're in good shape. There should be very little overhead in creating many proxy objects that share the same handler. A proxy object is just an empty object with a hidden reference to its handler. Be

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

arr has “0” as an own property > var subArr = Object.create(arr); > console.log(Reflect.has(subArr,”0”)); //true, all unshadowed properties > of proto visible from ordinary objects > var b = new ArrayView2(arr); > console.log(Reflect.has(b,”0”)); //true, prototype proxy makes array

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

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 pr

Re: Why Proxy "apply" trap limited to function only?

Oh. I didn't realize that. On Thu, Mar 3, 2016, 00:08 Kevin Smith wrote: > > I thought `typeof (class {}) === "function"` as well. And classes, to my >> knowledge aren't callable. >> > Oh they are, they just throw when you call them : ) > > >

Re: Why Proxy "apply" trap limited to function only?

> I thought `typeof (class {}) === "function"` as well. And classes, to my > knowledge aren't callable. > Oh they are, they just throw when you call them : ) https://tc39.github.io/ecma262/#sec-ecmascript-function-objects-call-thisargument-argumentslist Step 2

Re: Why Proxy "apply" trap limited to function only?

object is callable iff its typeof is 'function'. > By making the callability *and* the typeof of the proxy dependent on its > target, the two stay consistent. > > On Wed, Mar 2, 2016 at 6:51 AM, Олег Галабурда <burd...@gmail.com> wrote: > >> Yes, correct. I want to

Re: Why Proxy "apply" trap limited to function only?

We maintain the invariant that the typeof of an object is stable -- it never varies over time. An object is callable iff its typeof is 'function'. By making the callability *and* the typeof of the proxy dependent on its target, the two stay consistent. On Wed, Mar 2, 2016 at 6:51 AM, Олег

Re: Why Proxy "apply" trap limited to function only?

> Le 2 mars 2016 à 15:47, Caitlin Potter <caitpotte...@gmail.com> a écrit : > > You’re right. I would argue this warrants a non-normative pointer to > ProxyCreate() in the proxy [[CALL]] and [[CONSTRUCT]] internal methods. > > Thanks! Bug reported here: https://bugs.

Re: Why Proxy "apply" trap limited to function only?

> > > Rather, I'd say it is a bug in Chromium. > > A Proxy should have a [[Call]] internal method if and only if its target > has a [[Call]] internal method. See: > > http://www.ecma-international.org/ecma-262/6.0/#sec-proxycreate step 7. > > That maintains the equiv

Re: Why Proxy "apply" trap limited to function only?

You’re right. I would argue this warrants a non-normative pointer to ProxyCreate() in the proxy [[CALL]] and [[CONSTRUCT]] internal methods. Thanks! > On Mar 2, 2016, at 9:44 AM, Claude Pache <claude.pa...@gmail.com> wrote: > >> g signature.asc Description: Message signed

Re: Why Proxy "apply" trap limited to function only?

Yes, correct. I want to be able to make a callable Proxy for non-callable objects and don't understand why Proxies are having these restrictions. As you can see I, and any other developer, can easily bypass this restriction and make a wrapper function that actually will be never called and just

Re: Why Proxy "apply" trap limited to function only?

> Le 2 mars 2016 à 15:36, Caitlin Potter <caitpotte...@gmail.com> a écrit : > > As far as I can tell, this is a bug in Firefox / SpiderMonkey. The [[CALL]] > internal method of Proxy objects does not impose any restriction on the type > of the Proxy target. > >

Re: Why Proxy "apply" trap limited to function only?

As far as I can tell, this is a bug in Firefox / SpiderMonkey. The [[CALL]] internal method of Proxy objects does not impose any restriction on the type of the Proxy target. The following code behaves correctly in Chromium: ```js var proxy = new Proxy({}, { apply(target, thisArgument

Re: Why Proxy "apply" trap limited to function only?

object. > As example, this code: > > var api = new WorkerInterface('../webworker.js'); > api.requestTime(); > > When "requestTime" was requested, it calls "get" and immediately returns new > Proxy to serve function call. But at time when Proxy is created I

Re: Why Proxy "apply" trap limited to function only?

ow > what kind of object is this, so in case of function I should give ability > to make calls on the wrapper object. > As example, this code: > > var api = new WorkerInterface('../webworker.js'); > api.requestTime(); > > When "requestTime" was requested, it calls &qu

Re: Why Proxy "apply" trap limited to function only?

function I should give ability to > make calls on the wrapper object. > As example, this code: > > var api = new WorkerInterface('../webworker.js'); > api.requestTime(); > > When "requestTime" was requested, it calls "get" and immediately ret

Why Proxy "apply" trap limited to function only?

kind of object is this, so in case of function I should give ability to make calls on the wrapper object. As example, this code: var api = new WorkerInterface('../webworker.js'); api.requestTime(); When "requestTime" was requested, it calls "get" and immediately returns new Pro

Questions about Proxy.[[OwnPropertyKeys]] and the List type

I’m currently implementing section 9.5.11 of the spec ( https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys ). Sections 17 and 19 perform the Remove operation on the List type. How is the Remove operation defined? Is it defined to just delete

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On 02/19/2016 01:06 PM, Coroutines wrote: On Fri, Feb 19, 2016 at 1:03 PM, Tab Atkins Jr. wrote: On Fri, Feb 19, 2016 at 12:59 PM, Boris Zbarsky wrote: On 2/19/16 3:50 PM, Coroutines wrote: Side discussion: Why does Javascript have this limitation? -

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On Fri, Feb 19, 2016 at 1:03 PM, Tab Atkins Jr. wrote: > On Fri, Feb 19, 2016 at 12:59 PM, Boris Zbarsky wrote: >> On 2/19/16 3:50 PM, Coroutines wrote: >>> Side discussion: Why does Javascript have this limitation? - what I >>> view as a limitation?

  1   2   3   4   5   6   >