Re: has the syntax for proxies been finalized ?

2013-10-21 Thread Tom Van Cutsem
2013/10/18 Rick Waldron waldron.r...@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!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-21 Thread Tom Van Cutsem
2013/10/18 Allen Wirfs-Brock al...@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?)

Regards,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-21 Thread Allen Wirfs-Brock

On Oct 21, 2013, at 7:20 AM, Tom Van Cutsem wrote:

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

see 
http://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.

Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-21 Thread Tom Van Cutsem
2013/10/21 Allen Wirfs-Brock al...@wirfs-brock.com

 see
 http://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.


Got it, thanks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread Tom Van Cutsem
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


2013/10/18 Angus Croll anguscr...@gmail.com

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


 @angustweets

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


RE: has the syntax for proxies been finalized ?

2013-10-18 Thread Domenic Denicola
From: es-discuss [mailto:es-discuss-boun...@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:

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

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread David Bruant

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

https://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: 
https://bugzilla.mozilla.org/showdependencytree.cgi?id=703537hide_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: 
https://github.com/tvcutsem/harmony-reflect/blob/master/reflect.js where 
he's using the old API where available to implement the new one.


David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread Angus Croll
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

thanks!





On Oct 18, 2013, at 6:17, David Bruant bruan...@gmail.com wrote:

 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:
 https://github.com/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 
 http://wiki.ecmascript.org/doku.php?id=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:
 https://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: 
 https://bugzilla.mozilla.org/showdependencytree.cgi?id=703537hide_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: 
 https://github.com/tvcutsem/harmony-reflect/blob/master/reflect.js where he's 
 using the old API where available to implement the new one.
 
 David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


RE: has the syntax for proxies been finalized ?

2013-10-18 Thread Domenic Denicola
From: es-discuss [es-discuss-boun...@mozilla.org] on behalf of Angus Croll 
[anguscr...@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 http://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 :-/.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread Angus Croll
I can confirm:

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

and I'm good to go with ES6 proxy syntax

thanks all!

@angustweets


On Fri, Oct 18, 2013 at 7:49 AM, Angus Croll anguscr...@gmail.com wrote:

 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

 thanks!





 On Oct 18, 2013, at 6:17, David Bruant bruan...@gmail.com wrote:

 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:

 https://github.com/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
 http://wiki.ecmascript.org/doku.php?id=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:
 https://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:
 https://bugzilla.mozilla.org/showdependencytree.cgi?id=703537hide_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:
 https://github.com/tvcutsem/harmony-reflect/blob/master/reflect.js where
 he's using the old API where available to implement the new one.

 David


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread Rick Waldron
On Fri, Oct 18, 2013 at 10:53 AM, Domenic Denicola 
dome...@domenicdenicola.com wrote:

 From: es-discuss [es-discuss-boun...@mozilla.org] on behalf of Angus
 Croll [anguscr...@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 http://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? Thanks!

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread Angus Croll
No worries guys - thanks for adding the 'obsolete' note

@angustweets


On Fri, Oct 18, 2013 at 8:13 AM, Rick Waldron waldron.r...@gmail.comwrote:




 On Fri, Oct 18, 2013 at 10:53 AM, Domenic Denicola 
 dome...@domenicdenicola.com wrote:

 From: es-discuss [es-discuss-boun...@mozilla.org] on behalf of Angus
 Croll [anguscr...@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 http://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? Thanks!

 Rick


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread Rick Waldron
On Fri, Oct 18, 2013 at 11:19 AM, Angus Croll anguscr...@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 :)

Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread Angus Croll
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?



@angustweets


On Fri, Oct 18, 2013 at 12:33 AM, Tom Van Cutsem tomvc...@gmail.com 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


 2013/10/18 Angus Croll anguscr...@gmail.com

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


 @angustweets

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread André Bargull

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?


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





@angustweets

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread Angus Croll
thanks André that works!

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

@angustweets


On Fri, Oct 18, 2013 at 9:38 AM, André Bargull andre.barg...@udo.eduwrote:

  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?


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



 @angustweets


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread Allen Wirfs-Brock

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.1Proxy ( 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.1Proxy.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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


Re: has the syntax for proxies been finalized ?

2013-10-18 Thread Rick Waldron
On Friday, October 18, 2013, Angus Croll wrote:

 thanks André that works!

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

 Cc Tom Van Cutsem to make sure he sees this.

Rick




 @angustweets


 On Fri, Oct 18, 2013 at 9:38 AM, André Bargull 
 andre.barg...@udo.edujavascript:_e({}, 'cvml', 'andre.barg...@udo.edu');
  wrote:

  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?


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



 @angustweets



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


has the syntax for proxies been finalized ?

2013-10-17 Thread Angus Croll
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
http://wiki.ecmascript.org/doku.php?id=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?
thanks


@angustweets
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss