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: 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?

Sorry you all, I realized I should've simplified it. Here's a [simpler fiddle](https://jsfiddle.net/trusktr/tf6hdn48/6/). On Thu, Nov 21, 2019 at 1:17 PM #!/JoePea wrote: > > I was trying to implement "multiple inheritance" in the following code >

Re: Proxy target/handler access leak in Node

> Making is a public symbol in this manner means it is almost impossible to deny. It is still true that "util" is deniable, so this isn't necessarily fatal. I am not yet oriented enough to understand what the consequences are of suppressing util; but I am worried. I wasn’t under the impression

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

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 in the original issue thread. I would also not have thought to

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 (that the

Re: Proxy target/handler access leak in Node

In the browser, I could see why not to allow it by default: it's a potential security hole, and GC concerns do exist (what happens if the symbol's data is no longer accessible without reflection?). In embeddings, I'm not sure if there's any real problem, considering Node's `vm` API allows proper

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 pair of

Re: Proxy target/handler access leak in Node

This is indeed quite scary. I have never used of explored the Node `util` API. What is going on here? Can you explain? The Realms shim and SES (which build on the Realms shim) create an environment in which only those globals defined by EcmaScript, not by the host, are present by default.

Re: Proxy target/handler access leak in Node

Nicely done! One more reason to prefer WeakMaps to properties when relating objects and secrets. On Sun, Sep 16, 2018 at 2:59 PM Darien Valentine wrote: > A few weeks ago I’d commented on an open Node github issue regarding > Proxies and inspection. While the bulk of the comment concerns an

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?

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 higher performance proxies than we could without these subtle semantic changes? Or do you think we can as easily achieve these

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?

On Fri, Aug 4, 2017 at 4:52 PM, Allen Wirfs-Brock wrote: > > On Aug 4, 2017, at 2:22 PM, Mark S. Miller wrote: > > At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have an idea (that > we should turn into a proposal) for a subtle change to

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 are the

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?

On Fri, Aug 4, 2017 at 2:52 PM, Allen Wirfs-Brock wrote: > > On Aug 4, 2017, at 2:22 PM, Mark S. Miller wrote: > > At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have an idea > (that we should turn into a proposal) for a subtle change to

Re: Proxy

Agreed, but it lacks intent... I.e., the get handler doesn't know whether the return value is being called. Imagine a layer that is so robust and flexible that, to use it, you don't have to know or care how the things are used... You just do what makes sense and it works... this concept kinda

Re: Proxy

You can always just return a callable from `handler.get`. Function closures are much more 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

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 . I think I understand

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

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

Re: Proxy [[Construct]]

Thanks, changed it to an assert. Ideally, you should return this sort of thing using bugs.ecmascript.org. Allen On Jan 18, 2015, at 3:21 PM, Tom Schuster wrote: The Proxy [[Construct]] method 9.5.14, has the step 7.a If target does not have a [[Construct]] internal method, throw a

Re: Proxy objects and collection

On Tue, Sep 2, 2014 at 1:07 PM, Daurnimator q...@daurnimator.com wrote: I'm the maintainer of lua.vm.js[1], which allows Lua code to run in the browser. I've managed to construct a simple and robust cross-language bridge, so that Lua code can interact with Javascript objects. When the Lua no

Re: Proxy objects and collection

Daurnimator wrote: So, I'd like to see some sort of trap that is fired when a Proxy is collected. To prevent over specifying how Javascript garbage collectors should operate, I propose that the trap *may* only be called at some *undefined* point after the object is not strongly referenced.

Re: Proxy objects and collection

Daurnimator wrote: On 2 September 2014 14:41, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: Daurnimator wrote: So, I'd like to see some sort of trap that is fired when a Proxy is collected. To prevent over specifying how Javascript garbage

Re: Proxy objects and collection

Le 02/09/2014 20:07, Daurnimator a écrit : So, I'd like to see some sort of trap that is fired when a Proxy is collected. To prevent over specifying how Javascript garbage collectors should operate, I propose that the trap *may* only be called at some *undefined* point after the object is not

Re: Proxy objects and collection

Daurnimator wrote: On 2 September 2014 15:19, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: Indeed we do not want post-mortem resurrection, but any id would have the problem too, if it were strongly linked; and would have a similar problem if weak. Would it? If the

Re: Proxy objects and collection

On 2 September 2014 16:40, Brendan Eich bren...@mozilla.org wrote: Daurnimator wrote: If the object is freed before the trap, then the trap just gets some sort of object id. Then it can call out to the external resource manager: hey, resource id 123 isn't needed any more. Which could then free

Re: Proxy objects and collection

Daurnimator wrote: On 2 September 2014 16:40, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: Daurnimator wrote: If the object is freed before the trap, then the trap just gets some sort of object id. Then it can call out to the external resource manager: hey, resource

Re: Proxy .__proto__ is not getPrototypeOf?

not sure I understand but ... that makes no sense as hasProxyAsProto is not a Proxy it's inheriting from a Proxy so where is the surprise? it does what I'd expect it to do, pass through the inherited Proxy same as you pass through inherited get/set methods when creating from an object that has

Re: Proxy .__proto__ is not getPrototypeOf?

On May 5, 2014, at 10:40 AM, John Barton wrote: I'm hoping someone can explain this result which surprises me. If I create an object with a Proxy-ed prototype, the resulting object does not obey .__proto__ equal Object.getPrototypeOf(). For example: var aPrototype = {foo: 'foo'};

Re: Proxy .__proto__ is not getPrototypeOf?

2014-05-05 19:40 GMT+02:00 John Barton johnjbar...@google.com: I'm hoping someone can explain this result which surprises me. If I create an object with a Proxy-ed prototype, the resulting object does not obey .__proto__ equal Object.getPrototypeOf(). There's no such equivalence, even for

Re: Proxy .__proto__ is not getPrototypeOf?

On Mon, May 5, 2014 at 11:44 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On May 5, 2014, at 10:40 AM, John Barton wrote: I'm hoping someone can explain this result which surprises me. If I create an object with a Proxy-ed prototype, the resulting object does not obey .__proto__ equal

Re: Proxy .__proto__ is not getPrototypeOf?

On 5/5/14, 4:21 PM, John Barton wrote: Let me rephrase my question: why is the Proxy get even called in this case? Because the way __proto__ works is as if the JS implementation had done: (function() { protoGetter = Object.getPrototypeOf; Object.defineProperty(Object.prototype, __proto__,

Re: Proxy .__proto__ is not getPrototypeOf?

but that's exactly what I've replied to you already? Once again, `__proto__` is spec'd in the `Object.prototype` like this: ```javascript Object.defineProperty( Object.prototype, '__proto__', { configurable: true, get: function () { return Object.getPrototypeOf(this); },

Re: Proxy .__proto__ is not getPrototypeOf?

everything else passes through the `Object.prototype` of course, unless not intercepted or shadowed as shown already in my previous reply ... `Object.defineProperty(anyObject, '__proto__', {value: false})` On Mon, May 5, 2014 at 4:57 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote:

Re: Proxy .__proto__ is not getPrototypeOf?

Since you ask for a response: On Mon, May 5, 2014 at 11:30 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: not sure I understand but ... that makes no sense as hasProxyAsProto is not a Proxy it's inheriting from a Proxy so where is the surprise? it does what I'd expect it to

Re: Proxy .__proto__ is not getPrototypeOf?

that code is wrong and I don't know why or who would assume that accordingly with specs I'd rather file a bug in there, pointing at specs ... there are two places about __proto__, everything else/other interpretations are evil indeed take care On Mon, May 5, 2014 at 6:48 PM, John Barton

Re: Proxy-for-array transparency issues

2013/7/31 Allen Wirfs-Brock al...@wirfs-brock.com We could define a new predicate Array.isArrayLike with a proxy friendly extensions mechanism (@@isArrayLike). It wouldn't be the same test as Array.isArray and the result would be more a statement of intent than an absolute guarantee.

Re: Proxy-for-array transparency issues

On Jul 31, 2013 6:40 AM, Tom Van Cutsem tomvc...@gmail.com wrote: On the flip side: DOM nodelists, while behaviorally similar to arrays, also don't pass the Array.isArray test. Does this anger developers? Or is this common wisdom and people have learned to live with the differences between

Re: Proxy-for-array transparency issues

On Jul 29, 2013, at 7:04 PM, David Bruant wrote: Le 30/07/2013 03:09, Allen Wirfs-Brock a écrit : On Jul 29, 2013, at 5:11 PM, David Bruant wrote: Le 29/07/2013 20:41, Allen Wirfs-Brock a écrit : The legacy [[Class]] internal property conflated these two concepts. Sometimes it was used

Re: Proxy-for-array transparency issues

2013/7/30 Allen Wirfs-Brock al...@wirfs-brock.com On Jul 29, 2013, at 7:04 PM, David Bruant wrote: Le 30/07/2013 03:09, Allen Wirfs-Brock a écrit : On Jul 29, 2013, at 5:11 PM, David Bruant wrote: Nope. We would have had the same problems if we had kept [[Class]]. In ES=5.1 [[Class]] is

Re: Proxy-for-array transparency issues

tl;dr: I would argue that Array.isArray should return true for proxies-for-arrays. The other built-ins are less crucial and could stay the way they are. Summarizing the previous discussion: - I agree that it is not safe to generalize: a proxy for an X is not in general substitutable for X. - It

Re: Proxy-for-array transparency issues

/ * ArrayBuffer.isView // yup. The use cases for isView aren't all that clear to me. It could be // expressed a @@isView test if it has important use cases. / I'm not familiar enough with ArrayBuffers to understand the consequences. By analogy with Array.isArray, if a proxy-for-arraybuffer

Re: Proxy-for-array transparency issues

2013/7/30 Tom Van Cutsem tomvc...@gmail.com tl;dr: I would argue that Array.isArray should return true for proxies-for-arrays. The other built-ins are less crucial and could stay the way they are. What about WeakMaps? Maps? Sets? How is the line drawn between crucial and less crucial? How is

Re: Proxy-for-array transparency issues

2013/7/30 David Bruant bruan...@gmail.com 2013/7/30 Tom Van Cutsem tomvc...@gmail.com tl;dr: I would argue that Array.isArray should return true for proxies-for-arrays. The other built-ins are less crucial and could stay the way they are. What about WeakMaps? Maps? Sets? I meant the

Re: Proxy-for-array transparency issues

On Jul 30, 2013, at 1:25 AM, David Bruant wrote: 2013/7/30 Allen Wirfs-Brock al...@wirfs-brock.com On Jul 29, 2013, at 7:04 PM, David Bruant wrote: Le 30/07/2013 03:09, Allen Wirfs-Brock a écrit : On Jul 29, 2013, at 5:11 PM, David Bruant wrote: ... no special this here. I'm just

Re: Proxy-for-array transparency issues

Le 30/07/2013 18:57, Allen Wirfs-Brock a écrit : So far in ES=6 dealing with such private data slots is something that could be treated in a relatively ad hoc manner within the ES spec. and by implementations. But in ES7 we really want and need user definable per instance private data. The

Re: Proxy-for-array transparency issues

On Jul 30, 2013, at 12:40 PM, David Bruant wrote: Le 30/07/2013 18:57, Allen Wirfs-Brock a écrit : ... But it still doesn't work the way you would like for direct call invocation or for things like Array.isArray. The base issue for either of these is that they don't indirect through

Re: Proxy-for-array transparency issues

On Tue, Jul 30, 2013 at 10:19 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: I was really asking about purpose of application level Array.isArray tests. What is the application really asking when it uses that test? Is it really asking array-like? What counts as array-like? My guess is:

Re: Proxy-for-array transparency issues

On Jul 30, 2013, at 2:21 PM, Till Schneidereit wrote: On Tue, Jul 30, 2013 at 10:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: I was really asking about purpose of application level Array.isArray tests. What is the application really asking when it uses that test? Is it really

Re: Proxy-for-array transparency issues

Le 30/07/2013 22:19, Allen Wirfs-Brock a écrit : On Jul 30, 2013, at 12:40 PM, David Bruant wrote: Le 30/07/2013 18:57, Allen Wirfs-Brock a écrit : ... But it still doesn't work the way you would like for direct call invocation or for things like Array.isArray. The base issue for either

Re: Proxy-for-array transparency issues

On Wed, Jul 31, 2013 at 12:19 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Jul 30, 2013, at 2:21 PM, Till Schneidereit wrote: On Tue, Jul 30, 2013 at 10:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: I was really asking about purpose of application level Array.isArray

Re: Proxy-for-array transparency issues

On Jul 29, 2013, at 9:06 AM, Tom Van Cutsem wrote: Hi, Originally, direct proxies were specified such that a direct proxy would inherit the [[Class]] of the target object it wraps. The intent was for e.g. proxies-for-arrays to be recognized properly as arrays. In ES6 the [[Class]]

Re: Proxy-for-array transparency issues

Le 29/07/2013 20:41, Allen Wirfs-Brock a écrit : The legacy [[Class]] internal property conflated these two concepts. Sometimes it was used for to ensure that a built-in method was operating upon an instance that actually had the internal state or conformed to other implementation level

Re: Proxy-for-array transparency issues

David Bruant wrote: Also, I fail to understand the difference between if O is an exotic X object and if O.[[Class]] === X. +1 What have we gained? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Proxy-for-array transparency issues

On 7/29/2013 5:14 PM, Brendan Eich wrote: David Bruant wrote: Also, I fail to understand the difference between if O is an exotic X object and if O.[[Class]] === X. +1 What have we gained? It seems to me like duck-typing based on internal properties was basically superseded by @@create

Re: Proxy-for-array transparency issues

On Jul 29, 2013, at 5:11 PM, David Bruant wrote: Le 29/07/2013 20:41, Allen Wirfs-Brock a écrit : The legacy [[Class]] internal property conflated these two concepts. Sometimes it was used for to ensure that a built-in method was operating upon an instance that actually had the internal

Re: Proxy-for-array transparency issues

Le 30/07/2013 03:09, Allen Wirfs-Brock a écrit : On Jul 29, 2013, at 5:11 PM, David Bruant wrote: Le 29/07/2013 20:41, Allen Wirfs-Brock a écrit : The legacy [[Class]] internal property conflated these two concepts. Sometimes it was used for to ensure that a built-in method was operating

Re: Proxy questions

I want to stress this again: proxies, for all operations they can intercept, can always decide to go into an infinite loop or throw. If they do throw, they can't hide their attack from your code. In that sense they don't violate the code's integrity. The invariant enforcement mechanism is

Re: Proxy questions

Kevin Smith wrote: OK - but we can't have it both ways. We can't allow |this| to give us access to private data (regardless of the implementation) *and also* allow that |this| may be an untrusted proxy. If |this| grants access to private data, then it must be trustable. Anything else is

Re: Proxy questions

Does the stack unwind as with normal error handling? Does after bar get logged? (FF18 answers yes to the first and no to the second question.) I agree with FF18 here. OK. Consider this: class Purse { private balance; constructor() { balance = 0;

Re: Proxy questions

Before commenting on the general question, I'm confused about something in your code. How did a proxy get bound to this in your example? On Sun, Jan 20, 2013 at 10:49 AM, Kevin Smith khs4...@gmail.com wrote: Does the stack unwind as with normal error handling? Does after bar get logged?

Re: Proxy questions

Let me correct a typo in that last one: var blackHolePurse = new Purse(); var blackHole = new Proxy(blackHolePurse, { get: function(obj, name) { if (name === somethingInocuous) throw new Error(Up in smoke!); return obj[name]; } }); try {

Re: Proxy target as __proto__? (Re: Proxy's optional target)

2013/1/18 Claus Reinke claus.rei...@talk21.com PS. I probably shouldn't mention that Proxies' invariant checks only against own properties behave differently from how non Proxy objects behave, if a target prototype property happensto be frozen (override prohibition non-mistake)?

Re: Proxy target as __proto__? (Re: Proxy's optional target)

Hi Claus, I'm not sure I fully understand your proposal, but could you not achieve it by simply doing: var target = ...; // might be frozen var p = Proxy( Object.create(target), handler); ? Cheers, Tom 2013/1/17 Claus Reinke claus.rei...@talk21.com The proxy target is important because it

Re: Proxy target as __proto__? (Re: Proxy's optional target)

Hi Tom, I'm not sure I fully understand your proposal, but could you not achieve it by simply doing: var target = ...; // might be frozen var p = Proxy( Object.create(target), handler); Ah, too obvious for me, thanks! Also, proxy wrappers often modify functions, which tend to be on a

Re: Proxy-induced impurity of internal methods

2011/10/6 Andreas Rossberg rossb...@google.com A related nit: even for freeze and friends, the restriction on recursive fix is NOT enough as currently stated in the proxy semantics. Consider: -- var handler = { get fix() { Object.seal(p); return {} } } var p =

Re: Proxy-induced impurity of internal methods

Hi Andreas, These are all good points. Some comments below: 2011/10/5 Andreas Rossberg rossb...@google.com Proxies invalidate one fundamental assumption of the current ES spec, namely that (most) internal methods are effectively pure. That has a couple of consequences which the current proxy

Re: Proxy-induced impurity of internal methods

2011/10/6 Andreas Rossberg rossb...@google.com A related nit: even for freeze and friends, the restriction on recursive fix is NOT enough as currently stated in the proxy semantics. Consider: -- var handler = { get fix() { Object.seal(p); return {} } } var p =

Re: Proxy-induced impurity of internal methods

On 10 October 2011 15:38, Tom Van Cutsem tomvc...@gmail.com wrote: This point was previously noted, see: http://wiki.ecmascript.org/doku.php?id=strawman:proxy_set_trap It was brought up at the March 2011 meeting, and IIRC we were in agreement that the spec. should be adapted to remove the

Re: Proxy-induced impurity of internal methods

2011/10/10 Andreas Rossberg rossb...@google.com On 10 October 2011 16:01, Tom Van Cutsem tomvc...@gmail.com wrote: I will go over the proposed proxies spec to check whether there is actually any harm in allowing a proxy to become non-trapping during an active trap. If the proxy describes

Re: Proxy-induced impurity of internal methods

On 6 October 2011 06:34, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Oct 5, 2011, at 9:57 AM, Andreas Rossberg wrote: In summary, I'm slightly worried. The above all seems fixable, but is that all? Ideally, I'd like to see a more thorough analysis of how the addition of proxies affects

Re: Proxy-induced impurity of internal methods

On 5 October 2011 21:00, Andreas Rossberg rossb...@google.com wrote: On 5 October 2011 18:57, Andreas Rossberg rossb...@google.com wrote: FIXING PROXIES A particularly worrisome side effect is fixing a proxy. The proxy semantics contains a lot of places saying If O is a trapping proxy, do

Re: Proxy-induced impurity of internal methods

Please keep bringing these up; they're important. This is something that we'll need to get nailed down for the spec. Yes, I'm worried too, as this problem is not well-understood. It has the feel of a research problem. Waldemar ___ es-discuss

Re: Proxy-induced impurity of internal methods

On 5 October 2011 18:57, Andreas Rossberg rossb...@google.com wrote: FIXING PROXIES A particularly worrisome side effect is fixing a proxy. The proxy semantics contains a lot of places saying If O is a trapping proxy, do steps I-J. However, there generally is no guarantee that O remains a

Re: Proxy-induced impurity of internal methods

Good points that we will have to specify careful. Also one the reasons we do prototype implementations. Such issues seems inherent in the adoption of an intercession API and semantics. Having to deal with such issues isn't really new. In ES5 we had to deal with this possibility WRT [[Get]]

Re: Proxy semantics and Object.defineProperty

Good catch. It was not intentional to specify that normalized descriptors are necessarily complete. Actually, there are two cases to consider: - for defineProperty, the descriptor should not be completed, for exactly the reason you show. - for get{Own}PropertyDescriptor, in ES5 the result is

Re: Proxy semantics and Object.defineProperty

On Wed, Jul 13, 2011 at 10:55 AM, Tom Van Cutsem tomvc...@gmail.com wrote: Good catch. It was not intentional to specify that normalized descriptors are necessarily complete. Actually, there are two cases to consider: - for defineProperty, the descriptor should not be completed, for exactly

Re: Proxy forwarding handlers and accessor properties

I agree with all of David's points. I wonder though: would it make more sense if we'd spec. the get trap of Proxy.Handler as: get: function(name, proxy) { let val = this.target[name]; return typeof val === function ? val.bind(this.target) : val; } Then both method accessor