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. <http://wiki.ecmascript.org/doku.php?id=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.
> 
> Regards,
> Tom

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.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131018/cb885b2e/attachment-0001.html>

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. http://wiki.ecmascript.org/doku.php?id=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.