Issue 633  has been merged into this issue.

Now working:

- delete
- Object.getOwnPropertyDescriptor
- Object.seal, Object.freeze, and Object.preventExtension
- Object.isSealed, Object.isFrozen, and Object.isExtensible

Would love to see function proxies working. Not sure how applicable it would be to the integration into V8 core, but they have been implemented on top of V8 in https://github.com/samshull/node-proxy if that's helpful.

Sorry, I haven't updated this in a while. Also working:

- all Object.prototype methods
- in
- plus lots of bug fixes and corner cases

The function proxy implementation is currently under review and should land in a little while. See:

http://codereview.chromium.org/7623011/
http://codereview.chromium.org/7628021/

The first implementation is approaching completion. All of the following should now also be working:

- function proxies
- proxies as keys to WeakMaps
- proxies in the prototype chain
- elements (integer-indexed properties)
- descriptor conversion

The main features still missing are for-in loops and the with statement. Also, the API is not proxy aware yet.

Looks like there's a problem with the this-binding for function proxies. Running the attached file should print `42` not `undefined`. 

fproxy.js 1.8 KB   View   Download

Update: the implementation is feature-complete (and the above issue fixed).

The only known issues at the moment are:

1. Using `new' with a function proxy that does not have an explicit construct trap sometimes sets the wrong prototype.

2. A function proxy with a construct trap returning a non-object will no longer return the right result when frozen.

3. In some cases, the call trap of a function proxy will receive the global object even though the trap is a strict-mode function.

If you observe other issues, please report them here.

Awesome! When would app developers be able to use proxies in V8 without flag?

We have no immediate plans for that. The feature has to be field-tested first. Since it touches so many corners of the implementation, there is lots of opportunities for fatal bugs. So we want to be confident that everything works as expected before turning it on for everybody.

You can help by trying it out. :)

I think I may have encountered a bug regarding to the proxy implementation. Please see the attached script. For some reason, the following code does not work properly:

    var key = "foo";

    proxy["foo"] = "bar"; // triggers the `set` function on the proxy
    proxy[ key ] = "bar"; // does _not_ trigger the `set` function on the proxy (bug?)

proxytest.js 408 bytes   View   Download

Regarding comment #10, perhaps it might be useful to see a little more detail on what cases fail.

Given a proxy "proxy" with a "set" trap, only the "PASS" marked expressions of the following cases cause the "set" trap to be triggered. The "FAIL" marked expressions somehow do *not* make the "set" trap get triggered.

    var key = "foo";

    proxy.foo = "bar";         // PASS
    proxy["foo"] = "bar";      // PASS
    proxy["foo" + ""] = "bar"; // *FAIL*
    proxy[key] = "bar";        // *FAIL*
    proxy[123] = "bar";        // *FAIL*
    proxy["123"] = "bar";      // *FAIL*
    proxy["123foo"] = "bar";   // PASS

Does anyone know whether this behaviour is buggy or intended?

proxy_bug_tests.js 614 bytes   View   Download

That certainly is a bug. Thanks for reporting! I will look into it soon.

/Andreas

Hm, how did you run this, what architecture, and what version of V8 and/or Chrome? I'm afraid I cannot reproduce the failures in the D8 shell (with s/console.log/print/g), on none of our supported architectures.

I'm running V8 as part of Node.js version 0.6.5, which uses V8 version 3.6.6.11. I now see it's not the latest version, so perhaps it has been fixed already. In that case I'm sorry.

I'm not very technical but I can tell have an Intel T1400 processor.

Ah, OK. Yes, the proxy implementation is far from complete in that version of V8. You'd need to update to a more recent 3.7.x.

I'm sorry for posting again, but I would like to mention the following behaviour which I think is a bug. I can reproduce it with the latest revision.

When creating a proxy function, calling it works fine. However, passing it as the argument to e.g. `Array.prototype.map` fails. It throws "illegal access" in that case.

Please see the attached test case.

proxy_func_map.js 302 bytes   View   Download

Thanks for the bug report! Yes, this is a bug, the fix should land soon.

See: https://chromiumcodereview.appspot.com/9270004/

There seems to be an issue with the getOwnPropertyNames and keys traps, when they return property names that are also present in Object.prototype. Somehow this raises a TypeError that duplicate property names were returned. See the attached testcase.

prototype_keys_bug.js 463 bytes   View   Download

Hi Tom, thanks for the bug report.

I fixed this (including the broken error message with the "undefined" trap name), and also the receiver bug you point out on github (https://github.com/tvcutsem/harmony-reflect/issues/4#issuecomment-5831098).

On the other hand, as you probably have guessed, the fact that V8 does not call the `has' trap separately for assignment to inherited properties is intentional, and should match the refactored spec.

When will this land? I've been waiting for this feature to be available in v8 and Chrome

If you are referring to proxies in Javascript, it already landed, but hidden behind a flag. To turn it on, go to chrome://flags/ and "Enable Experimental JavaScript".

Google Apps Script's Html Service relies on Firefox's proxies implementation and falls back on a much less efficient hack on other browsers; it would be great for us if it could come out from behind the flag soon.

How much are they relying on it? Firefox implementation is incomplete and has many known (and likely unknown!) bugs.
Also, to my knowledge, current V8 implementation relates to the old Proxy design. I don't think work to support direct proxies has started (if I'm wrong, please point me to the right V8 bug)

Re: comment 23 -- "(and likely unknown!) bugs" is LOL unreal. Since when did V8 ship without unknown bugs? How do you prove a negative?

How are you going to find and fix proxy bugs that Google itself seems to want fixed, without turning on proxies? How are you going to help fix the ES6 draft spec, which we helped get in shape by prototyping proxies two years ago?

Fear of bugs does not prevent all sorts of innovation from being shipped in Chrome -- some of it on no standards track and very unlikely ever to be.

BTW SpiderMonkey supports direct proxies (yes, with bugs -- please file them as they become known) now. Time to get V8 interop-testing so we can fix the spec as well as the implementations, and lead the other browsers to implement as well.

/be

Ghostery, a popular privacy extension for browsers, is waiting on Proxies in V8 to provide better script surrogation to its users.

Script surrogation is the act of replacing blocked tracker scripts with dummy copies in order to allow badly-coded websites to continue to function. However, listing out every method call for every tracker script isn't scalable.

__noSuchMethod__ is Firefox-only and deprecated. Proxies are the future, but have been "on the way" for a while now.

Any plans on when this is going to be implemented?

Proxies are still seeing a lot of churn in the ES6 draft so it seems better to wait until the API stabilizes a bit more.

By "this" you mean?

No concrete plans right now. There is some likelihood that the ES6 proxy design will undergo another substantial change, so it seems wiser to hold off.

I'm sorry, guys. By "this" I meant proxies, of course.

Thanks for the info!

hg7fb9fu6qn9

"Proxies are still seeing a lot of churn in the ES6 draft so it seems better to wait until the API stabilizes a bit more."
"There is some likelihood that the ES6 proxy design will undergo another substantial change, so it seems wiser to hold off."
=> At the May 2013 TC39 meeting, it's been agreed that direct proxies (new Proxy(target, handler)) would be the final design.
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-05/may-21.md#44-proxies

From what I know, the design is now very stable. Maybe time to reconsider? :-)

The Node.js team has a use for direct proxies: allowing us to create fake globals that intercept defineProperties on them for use in the vm module. Currently we use ObjectTemplate which has GlobalPropertyGetterCallback, GlobalPropertySetterCallback, GlobalPropertyQueryCallback, GlobalPropertyDeleterCallback, GlobalPropertyEnumeratorCallback, but this does not encompass all operations. In particular, it does not have defineProperty, so if people declare global functions inside the vm, we have no way to intercept that.

If direct proxies were available, we could turn them on in V8, then use them to implement this desired proxying behavior. As is, we shouldn't turn on --harmony-proxies, because then Node.js consumers would start using the old API.

More details about the particular use case at https://github.com/joyent/node/pull/6417.

Since harmony is almost finished, can we get any idea of when updating proxies to match the direct proxy design will start being looked at?

ES6 comes with a _lot_ of new features, many of which we still have to work on. To be honest, proxies are not at the top of our priority list.

I'm not asking for a fully functional direct proxy implementation in chrome (V8), all I would like to know is that when ES6 comes out I'm gonna be able to use the same code in firefox and chrome (with direct proxies).
Is there any chance for that?

You can achieve writing the same Proxy code for firefox, chrome and node today by using my shim:
<https://github.com/tvcutsem/harmony-reflect>
It's not perfect, but people are using it so it could be useful in the short term.

It is very unlikely that we are going to be finished with implementing all of ES6 the day the standard is officially sanctioned, if that's what you are asking.

Thats obvious, my quetion was only about direct proxies since their implementation is nearly complete in gecko.

I thought I already answered that: it's not high on our priority list, so it gets done when we get to it. The ES6 spec release date has no more influence on proxies than on any other ES6 feature.

A stable proxies implementation could also help us on the Atom team. We'd love to start experimenting with membranes to implement sophisticated security policies.

(No comment was entered for this change.)

I'd just like to add a friendly +1 here. Been experimenting with proxies a lot in FF, and I'm very eagerly awaiting this in V8.

@Ross wouldn't it better to finish implementing ES6 before the standard is officially sanctionned, so you can give some implementor feedback before shipping flawed specs ?

Anyway, we're really looking forward to be able to use ES6 feature :)

Looks like the old Proxy (pre-direct) implementation was removed, so harmony-reflect no longer works. Is there any intention to restore the old Proxy, or will it be gone until the ES6 direct-proxy implementation is ready?

It wasn't removed. It was removed from --harmony due to some security(?) issues. Try using --harmony-proxies instead.

I think my issue belongs in the chromium issue tracker instead of here - it's no longer exposed to the browser, although it is available in v8. Sorry for the confusion.

Where can I read more about the (security?) issues that caused the old Proxy object to be removed? Thanks.

#46: no reason to report this on chromium, here was the right place.

(No comment was entered for this change.)