Discuss
  • has the syntax for proxies been finalized ?

has the syntax for proxies been finalized ?

# Angus Croll (11 years ago)

I couldn't find a commitment to a specific syntax in the latest ES6 standard

Gecko, chrome experimental, traceur and 'node --harmony-proxies' support the Proxy.create syntax (detailed in harmony:proxies)

e.g.

var proxy = Proxy.create({
 get: function(p, n) {
  return 'Hello ' + n;
 }
});
proxy.World //'Hello World'

However MDN calls the above the 'Old Proxy API'. Gecko also supports what MDN indicates implies is the current Proxy syntax (i.e. new Proxy) e.g.

var p = new Proxy(
  {},
  {get: function(p,x) {
    return 'Hello ' + x
  }}
);
p.World; //'Hello World'

Which is right?

# Tom Van Cutsem (11 years ago)

Proxy.create and Proxy.createFunction are deprecated.

The correct syntax is new Proxy(target, handler)

In my original direct proxies proposal, the new was optional, so that var p = Proxy(target, handler) works equally well (cf. harmony:direct_proxies)

Since then, it seems people want to move away from implicit construction (since it doesn't interact well with class inheritance), so I don't know if there is still consensus on this.

In the prototype Firefox implementation, new is currently mandatory.

# Domenic Denicola (11 years ago)

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Angus Croll

I couldn't find a commitment to a specific syntax in the latest ES6 standard

It's not quite fleshed out yet, but the constructor function is at least there:

people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-objects

# David Bruant (11 years ago)

Le 18/10/2013 07:19, Angus Croll a écrit :

I couldn't find a commitment to a specific syntax in the latest ES6 standard

The latest official news is in the May 2013 TC39 notes: rwaldron/tc39-notes/blob/master/es6/2013-05/may-21.md#44-proxies The final design of proxies is the "direct proxies" design. As Tom said, a proxy is now created doing:

 var p = Proxy(target, handler)

Proxy.create and Proxy.createFunction are aimed at disappearing.

Gecko, chrome experimental, traceur and 'node --harmony-proxies' support the Proxy.create syntax (detailed in harmony:proxies)

e.g.

var proxy = Proxy.create({
 get: function(p, n) {
  return 'Hello ' + n;
 }
});
proxy.World //'Hello World'

On the SpiderMonkey (Gecko implements the DOM and other platform APIs and SpiderMonkey is the part that implement ECMAScript) side, I filed a bug to get rid of these as it's indeed confusing to have both APIs exposed in web pages: bugzilla.mozilla.org/show_bug.cgi?id=892903

IIRC, the V8 team had started implementing something (behind a flag), and then wars on Proxy design happened, so they chose to wait for the design to stabilize. Now may be a good time to restart

However MDN calls the above the 'Old Proxy API'.

I'm glad I succeeded in, at least, making people wonder what that was all about :-)

Since I've been following closely the design of proxies, I documented them on MDN. Especially after the implementation of direct proxies in Firefox (where I moved the documentation of the previous API to its own page and try to explain the best I could that people should not use it). I'm happy to improve the doc if something isn't clear (on the feature itself or clarify the current technico-social mess of different APIs in the wild).

As a side note, to my knowledge, the only native implementation of direct proxies is in Firefox, but it's incomplete and has known bugs. You can see the known limitations and bugs here: bugzilla.mozilla.org/showdependencytree.cgi?id=703537&hide_resolved=1 ("depends on" section. Bug 787710 is particularly funny :-)).

If you want to play with proxies, I think that the most faithful-to-the-spec implementation is Tom's polyfill: tvcutsem/harmony-reflect/blob/master/reflect.js where he's using the old API where available to implement the new one.

# Angus Croll (11 years ago)

Great info thanks (and Tom and Domenic)

A note on MDN confirming that direct proxy adhered to the new spec (and a similar one on old proxy saying it didn't) would probably be immensely helpful to other people who had the same question I had.

Also (to all) deleting or marking as obsolete all wiki-harmony docs that no longer meet the standard would save a lot of wasted hours

# Domenic Denicola (11 years ago)

From: es-discuss [es-discuss-bounces at mozilla.org] on behalf of Angus Croll [anguscroll at gmail.com

Also (to all) deleting or marking as obsolete all wiki-harmony docs that no longer meet the standard would save a lot of wasted hours

I know Rick has already made strides in that direction via warnings like

"This API is superseded by the newer direct proxies API."

or

This proposal has progressed to the Draft ECMAScript 6 Specification (Sept. 2013 draft Sections 9.3 and 26.2), which is available for review here: specification_drafts. Any new issues relating to them should be filed as bugs at bugs.ecmascript.org. The content on this page is for historic record only and may no longer reflect the current state of the feature described within.

But I somewhat agree that the warnings are not scary enough. Something drastic like moving the entire page to "obsolete:proxies" would be nice. But, eh, broken links :-/.

# Angus Croll (11 years ago)

I can confirm:

npm install harmony-reflect
node --harmony
> require('harmony-reflect')

and I'm good to go with ES6 proxy syntax

thanks all!

# Rick Waldron (11 years ago)

On Fri, Oct 18, 2013 at 10:53 AM, Domenic Denicola < domenic at domenicdenicola.com> wrote:

From: es-discuss [es-discuss-bounces at mozilla.org] on behalf of Angus Croll [anguscroll at gmail.com

Also (to all) deleting or marking as obsolete all wiki-harmony docs that no longer meet the standard would save a lot of wasted hours

@Angus, I'm sorry this happened, I try to keep up with marking wiki docs' status as best as I can.

I know Rick has already made strides in that direction via warnings like

"This API is superseded by the newer direct proxies API."

or

This proposal has progressed to the Draft ECMAScript 6 Specification (Sept. 2013 draft Sections 9.3 and 26.2), which is available for review here: specification_drafts. Any new issues relating to them should be filed as bugs at bugs.ecmascript.org. The content on this page is for historic record only and may no longer reflect the current state of the feature described within.

But I somewhat agree that the warnings are not scary enough. Something drastic like moving the entire page to "obsolete:proxies" would be nice. But, eh, broken links :-/.

I'm all for suggestions to make it even more clear, as long as those suggestions don't break links (as Domenic has mentioned here). Currently, the "old" proxy proposals are stricken on the harmony:proposals page and the direct proxies proposal includes the "progressed to draft" text.

FWIW, I've added "The content on this page is OBSOLETE" to the three oldest proxy proposals.

@Tom - since you know the status of the more recent Proxy wiki pages better than I do, would you mind adding the same h1 text to those that fit the description of "obsolete"?

# Angus Croll (11 years ago)

No worries guys - thanks for adding the 'obsolete' note

# Rick Waldron (11 years ago)

On Fri, Oct 18, 2013 at 11:19 AM, Angus Croll <anguscroll at gmail.com> wrote:

No worries guys - thanks for adding the 'obsolete' note

Don't hesitate to ask for clarification on this list—especially if you think it will save you time :)

# Angus Croll (11 years ago)

Follow up question for Tom et al...

Using require('harmony-reflect')....

var t = {a:3, c:4};
var p = Proxy(
  t,
  {
    get: function() {},
    delete: function(t,x) {
      console.log('deleting');
      delete t.a;
    }
  }
);
delete p.c
p; //{a:3}
t; //{a:3}

the console.log is not called and deleting is not trapped. Am I doing something wrong?

# André Bargull (11 years ago)

Am I doing something wrong?

The trap name for the delete operator is "deleteProperty" instead of "delete"...

# Allen Wirfs-Brock (11 years ago)

On Oct 18, 2013, at 12:33 AM, Tom Van Cutsem wrote:

Proxy.create and Proxy.createFunction are deprecated.

The correct syntax is new Proxy(target, handler)

In my original direct proxies proposal, the new was optional, so that var p = Proxy(target, handler) works equally well (cf. harmony:direct_proxies)

Since then, it seems people want to move away from implicit construction (since it doesn't interact well with class inheritance), so I don't know if there is still consensus on this.

In the prototype Firefox implementation, new is currently mandatory.

This is what I currently have in my working draft of the ES6 spec:

26.2.1 The Proxy Factory Function

26.2.1.1 Proxy ( target, handler) The Proxy function is used to create an irrevocable Proxy object When Proxy is called with arguments target and handler the following steps are taken:

  1. Let p be ProxyCreate(target, handler).
  2. Return p.

26.2.2 Properties of the Proxy Factory Function

26.2.2.1 Proxy.revocable ( target, handler ) The Proxy.revocable function takes two arguments target and handler, and performs the following: The Proxy.revocable function is used to create a revocable Proxy object When Proxy.revocable is called with arguments target and handler the following steps are taken:

  1. Let p be ProxyCreate(target, handler).
  2. ReturnIfAbrupt(p).
  3. Let revoker be a new built-in function object as defined in 26.2.2.1.1.
  4. Set the [[RevokableProxy]] internal slot of revoker to p.
  5. Let result be the result of ObjectCreate().
  6. CreateOwnDataProperty(result, "proxy", p).
  7. CreateOwnDataProperty(result, "revoke", revoker).
  8. Return result.

26.2.2.1.1 Proxy Revocation Functions A Proxy revocation function is an anonymous function that has the ability to invalidate a specific Proxy object. Each Proxy revocation function has a [[RevokableProxy]] internal slot. When a Proxy revocation function, F, is called the following steps are taken:

  1. Let p be the value of F’s [[RevokableProxy]] internal slot.
  2. If p is undefined, then return undefined.
  3. Set the value of F’s [[RevokableProxy]] internal slot to undefined.
  4. Assert: p is a Proxy object.
  5. Set the [[ProxyTarget]] internal slot of p to undefined.
  6. Set the [[ProxyHandler]] internal slot of p to undefined.
  7. Return undefined.

In other words: you can say: Proxy(traget,handler) but not new Proxy(target, handler)

It would be easy enough to allow new Proxy(target,handler) but I'm not sure it is the best way to expose the Proxy abstraction .

Proxy really isn't a "class". There is no Proxy.prototype object and obj instanceof Proxy isn't useful. Also the @@create protocol really isn't right for instantiating Proxies. Subclassing a Proxy isn't going to give you anything that is useful.

I think we're now in a position where it would be reasonable to say that 'new" is the preferred way to instantiate instances of class-like constructors. Object that represent other kinds of abstractions shouldn't be created using 'new' but instead should be created with a simple function call (arguably, Symbol is another example where we allow Symbol() but not new Symbol()).

So, I'd prefer to go with what I've currently specified, but if the concensus is for 'new' I will change it.

# Angus Croll (11 years ago)

thanks André that works!

(I was going by tvcutsem/harmony-reflect/blob/master/doc/traps.md which says 'delete')

# Rick Waldron (11 years ago)

On Friday, October 18, 2013, Angus Croll wrote:

(I was going by tvcutsem/harmony-reflect/blob/master/doc/traps.mdwhich says 'delete')

Cc Tom Van Cutsem to make sure he sees this.

# Angus Croll (11 years ago)

thanks - I made a PR

# Tom Van Cutsem (11 years ago)

2013/10/18 Rick Waldron <waldron.rick at gmail.com>

@Tom - since you know the status of the more recent Proxy wiki pages better than I do, would you mind adding the same h1 text to those that fit the description of "obsolete"? Thanks!

Done!

# Tom Van Cutsem (11 years ago)

2013/10/18 Allen Wirfs-Brock <allen at wirfs-brock.com>

This is what I currently have in my working draft of the ES6 spec:

[...]

In other words: you can say: Proxy(traget,handler) but not new Proxy(target, handler)

It would be easy enough to allow new Proxy(target,handler) but I'm not sure it is the best way to expose the Proxy abstraction .

Proxy really isn't a "class". There is no Proxy.prototype object and obj instanceof Proxy isn't useful. Also the @@create protocol really isn't right for instantiating Proxies. Subclassing a Proxy isn't going to give you anything that is useful.

I agree with your line of reasoning and I would be happy if proxies can be created without new. However, I don't see how the above spec disallows the use of new. With the above definition, won't new Proxy(target, handler) just work? (since the Proxy function just ignores its this-binding?)

# Allen Wirfs-Brock (11 years ago)

see people.mozilla.org/~jorendorff/es6-draft.html#sec-standard-built-in-ecmascript-objects Paragraph 9:

"Built-in functions that are not identified as constructors do not implement the [[Construct]] internal method unless otherwise specified in the description of a particular function."

# Tom Van Cutsem (11 years ago)

Got it, thanks.