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_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
