Re: On revoking access to the target of a proxy

2012-09-18 Thread Tom Van Cutsem
FYI, the ideas expressed in this thread are now written up as a strawman: http://wiki.ecmascript.org/doku.php?id=strawman:revokable_proxies Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: July 26, 2012 TC39 Meeting Notes

2012-09-18 Thread Tom Van Cutsem
I wrote up a strawman that summarizes the discussion on proxies private names in this thread: http://wiki.ecmascript.org/doku.php?id=strawman:proxies_names There are still some open issues though. Cheers, Tom ___ es-discuss mailing list

Re: July 26, 2012 TC39 Meeting Notes

2012-09-18 Thread Tab Atkins Jr.
On Tue, Sep 18, 2012 at 10:12 AM, Tom Van Cutsem tomvc...@gmail.com wrote: I wrote up a strawman that summarizes the discussion on proxies private names in this thread: http://wiki.ecmascript.org/doku.php?id=strawman:proxies_names There are still some open issues though. I like it! Seems

Re: July 26, 2012 TC39 Meeting Notes

2012-09-18 Thread Tom Van Cutsem
2012/9/18 Tab Atkins Jr. jackalm...@gmail.com Changing to an unknownPrivateName() trap is interesting. It seems kinda weird to be a *trap*, rather than just a property on the handler object, though. Is there a good reason to have that be dynamic? Well, you could indeed define it as a

Re: July 26, 2012 TC39 Meeting Notes

2012-09-18 Thread David Bruant
Le 18/09/2012 10:44, Tab Atkins Jr. a écrit : On Tue, Sep 18, 2012 at 10:12 AM, Tom Van Cutsem tomvc...@gmail.com wrote: I wrote up a strawman that summarizes the discussion on proxies private names in this thread: http://wiki.ecmascript.org/doku.php?id=strawman:proxies_names There are still

Re: Performance concern with let/const

2012-09-18 Thread Andreas Rossberg
On 17 September 2012 18:37, Luke Hoban lu...@microsoft.com wrote: 'let' is certainly not going to be faster than 'var' in any case There is at least one very important counterexample to that claim: the global scope. Assuming lexical global scope (as we tentatively agreed upon at the last

Re: Performance concern with let/const

2012-09-18 Thread Allen Wirfs-Brock
On Sep 18, 2012, at 7:27 AM, Andreas Rossberg wrote: On 17 September 2012 19:51, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 17, 2012, at 12:37 PM, Luke Hoban wrote: These are good questions. Paul will be attending the TC39 meeting this week, and can likely talk to specific

Re: Re: The joys of United flight 242

2012-09-18 Thread Douglas Crockford
On 2012-09-17 10:04 PM, Brendan Eich wrote: Moral of this story: avoid United. /be I have had similar experiences on Alaska, Delta, and long, long ago on Amtrak. The moral is more complicated than that. There may be an important meta-moral here.

Re: Performance concern with let/const

2012-09-18 Thread Andreas Rossberg
On 18 September 2012 13:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Yes but but there are fairly simple heuristics that approximate that result, for example: if no function calls dominate the initialization of x then TDZ checks will never need to be made for x Yes, except that in

Room/building number for the meeting?

2012-09-18 Thread Nebojša Ćirić
For some reason I can't open document repository to look at the latest venue document. The last one I have says that the room is still unknown. -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org

Re: Some questions about Private Name Objects

2012-09-18 Thread Rick Waldron
I just spoke to Allen and need to make a correction the post above: computed properties were, in fact, later dropped. Rick On Fri, Sep 14, 2012 at 5:34 PM, Irakli Gozalishvili rfo...@gmail.comwrote: Hey Dean, I also really love clojure protocols and in fact tried to propose few extensions

Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)

2012-09-18 Thread François REMY
My point is: how do you make sure you don't redefine an existing syntax? Or, if that the syntax you're defining for your personnal use will not be reclaimed by a next version of ES? // Polyfill for syntaxFeature: /*@cc_on /*@if !support syntaxFeature */ code that

Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)

2012-09-18 Thread Brendan Eich
François REMY wrote: My point is: how do you make sure you don't redefine an existing syntax? Or, if that the syntax you're defining for your personnal use will not be reclaimed by a next version of ES? // Polyfill for syntaxFeature: /*@cc_on /*@if !support syntaxFeature */

Re: JS syntax future-proofing, Macros, the Reader (was: Performance concern with let/const)

2012-09-18 Thread David Herman
It's still early to say. But my feeling is that if we can get macros working, we can introduce new syntax via modules, not just unconditionally throwing them in everywhere. Then you don't have to do these kinds of global conditional things; rather, you just import the syntax from modules. The

Re: About bugfix: For ISO 8601 syntax, Date.parse should accept in places where T is allowed

2012-09-18 Thread Norbert Lindenberg
Hi Colin, When changing the implementation of a standard built-in function that's defined in the ECMAScript Language Specification, you should always check the specification: http://ecma-international.org/ecma-262/5.1/ In this case, it seems your extension of the accepted formats is allowed by

Re: About bugfix: For ISO 8601 syntax, Date.parse should accept in places where T is allowed

2012-09-18 Thread Allen Wirfs-Brock
This is the response I posted to the bugzilla issue: I would like to see a better motivation present for why this change is important. In particular, it is a deviation from the ECMAScript standard. While syntactic extensions to the Date.parse syntax is allowed by the specification. It is

Re: About bugfix: For ISO 8601 syntax, Date.parse should accept in places where T is allowed

2012-09-18 Thread Sigbjorn Finne
On Wed, Sep 19, 2012 at 3:46 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: This is the response I posted to the bugzilla issue: I would like to see a better motivation present for why this change is important. In particular, it is a deviation from the ECMAScript standard. While