[Harmony Proxies] get/set trap receiver argument unnecessary

2011-04-27 Thread Sean Eagan
Hi, The get and set traps currently have both receiver and proxy arguments. This is because it has been suggested that they are not the same in the case of property access on a receiver causing a [[Get]] / [[Put]] call to propogate up the prototype chain to a proxy. From what I can tell though,

Re: [Harmony Proxies] get/set trap receiver argument unnecessary

2011-04-27 Thread David Bruant
Le 27/04/2011 19:38, Sean Eagan a écrit : Hi, The get and set traps currently have both receiver and proxy arguments. This is because it has been suggested that they are not the same in the case of property access on a receiver causing a [[Get]] / [[Put]] call to propogate up the prototype

Re: [Harmony Proxies] get/set trap receiver argument unnecessary

2011-04-27 Thread Sean Eagan
Hi David, On Wed, Apr 27, 2011 at 1:17 PM, David Bruant david.bru...@labri.fr wrote: The case when they are not the same is when the proxy is in the prototype chain (regardless of what kind of object is underneath). See the third example at:

Re: [Harmony Proxies] get/set trap receiver argument unnecessary

2011-04-27 Thread David Bruant
Le 27/04/2011 20:37, Sean Eagan a écrit : Hi David, On Wed, Apr 27, 2011 at 1:17 PM, David Bruant david.bru...@labri.fr wrote: The case when they are not the same is when the proxy is in the prototype chain (regardless of what kind of object is underneath). See the third example at:

Re: [Harmony Proxies] get/set trap receiver argument unnecessary

2011-04-27 Thread Sean Eagan
This can also be seen by realizing that if proxyA's handler uses the default get and set trap implementations, and proxyB is proxyA's [[Prototype]], then proxyB's get and set traps will not be called due to property access on proxyA, but rather its getPropertyDescriptor trap. Thanks, Sean Eagan

Re: [Harmony Proxies] get/set trap receiver argument unnecessary

2011-04-27 Thread Sean Eagan
Sorry, ignore the first paragraph in my last post, I included it at the end instead. Thanks. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: [Harmony Proxies] get/set trap receiver argument unnecessary

2011-04-27 Thread David Bruant
Le 27/04/2011 21:15, Sean Eagan a écrit : This can also be seen by realizing that if proxyA's handler uses the default get and set trap implementations, and proxyB is proxyA's [[Prototype]], then proxyB's get and set traps will not be called due to property access on proxyA, but rather its

Scoped Object Extensions strawman

2011-04-27 Thread Peter Hallam
Folks, I've added a strawman for scoped object extensionshttp://wiki.ecmascript.org/doku.php?id=strawman:scoped_object_extensionsto the ES Wiki. Scoped object extensions allows different libraries to define and reuse monkey patches without conflicting with each other. I've asked John to add

Re: [Harmony Proxies] get/set trap receiver argument unnecessary

2011-04-27 Thread Sean Eagan
On Wed, Apr 27, 2011 at 2:46 PM, David Bruant david.bru...@labri.fr wrote: You're right. get and set default traps were chosen to follow closely internal methods (see [1]) and at the time when proxy wasn't an argument of all traps (so a proxy's prototype wasn't reachable from the handler). It

Re: [Harmony Proxies] get/set trap receiver argument unnecessary

2011-04-27 Thread Brendan Eich
On Apr 27, 2011, at 2:09 PM, Sean Eagan wrote: As explained before, the existing ES5 semantics would cause the proxy's getPropertyDescriptor trap to be called thus obtaining any getter / setter that the proxy wants. The |this| binding of this getter / setter will then be set to the receiver

Agenda for i18n meeting in May

2011-04-27 Thread Nebojša Ćirić
As we agreed before we won't have face to face meeting in May in Santa Cruz. I'll be organizing teleconference call on *05*/*23*/2011, *10*-*17*h. John Neumann asked me to provide agenda for the next meeting. I hope to have a working prototype (Chrome based) with samples by the time of the

wiki feed - recent changes: extraneous html encoding in links?

2011-04-27 Thread Claus Reinke
The ecmascript wiki feed for recent changes http://wiki.ecmascript.org/feed.php appears to HTML encode its links, which causes the wiki to fall back to display pages, rather than diffs. For instance http://wiki.ecmascript.org/doku.php?id=strawman:strawmanamp;do=diffamp;1303930654 should be

Re: wiki feed - recent changes: extraneous html encoding in links?

2011-04-27 Thread David Herman
Hi Claus, Thanks for the bug report. I'm afraid I just don't have time for site sysadminning at the moment. Eventually we are hoping to upgrade the wiki and move it to our own (more reliable) servers, rather than the 3rd party server it's currently hosted on. But I won't be able to work on