Re: Refutable pattern

2013-02-05 Thread Brendan Eich
Brendan Eich wrote: Sorry if I was a thread-killer, posting four times in a row. On balance we have: prefix-? pros: * LR(1) grammar without ambiguity or lookahead restriction. Forgot to add the one Andreas cited: * Easier to see prefix-? in front of long object or array pattern. /be pref

Re: Refutable pattern

2013-02-05 Thread Brendan Eich
Sorry if I was a thread-killer, posting four times in a row. On balance we have: prefix-? pros: * LR(1) grammar without ambiguity or lookahead restriction. prefix-? cons: * ASI hazard if ? starts an intended destructuring assignment expression. suffix-? pros: * Matches CoffeeScript * Matches o

Re: Action proxies

2013-02-05 Thread Brendan Eich
David Bruant wrote: About the performance argument, I think a performance argument can only be made in comparison with what we have and not in absolute terms. Agreed, and I wrote taking that into account. What's at stake with notification proxies is getting rid of invariant checks [1]. For so

Re: How can a lexer decide a token to be "get", "IdentifierName" or "Identifier" ?

2013-02-05 Thread Allen Wirfs-Brock
Right, I think "mixin" is winning over "define" as the name. Same semantics in either case. Allen On Feb 5, 2013, at 9:03 AM, Rick Waldron wrote: > > > > On Tue, Feb 5, 2013 at 11:55 AM, Brandon Benvie > wrote: > Indeed, and given use of ES6, I expect things like this wouldn't be very >

Re: How can a lexer decide a token to be "get", "IdentifierName" or "Identifier" ?

2013-02-05 Thread Rick Waldron
On Tue, Feb 5, 2013 at 11:55 AM, Brandon Benvie wrote: > Indeed, and given use of ES6, I expect things like this wouldn't be very > uncommon (I think is supposed to be Object.define right?): > Nothing there yet, though I suspect Object.mixin() will have more traction. https://mail.mozilla.org/pi

Re: How can a lexer decide a token to be "get", "IdentifierName" or "Identifier" ?

2013-02-05 Thread Brandon Benvie
Indeed, and given use of ES6, I expect things like this wouldn't be very uncommon (I think is supposed to be Object.define right?): Object.define(x, { get a(){}, set a(v){}, get b(){}, c(){} }); Instead of most current descriptor stuff (since enumerability and configurability are rarely d

Re: How can a lexer decide a token to be "get", "IdentifierName" or "Identifier" ?

2013-02-05 Thread Rick Waldron
On Tue, Feb 5, 2013 at 3:19 AM, gaz Heyes wrote: > On 4 February 2013 23:44, Brendan Eich wrote: > >> What's confusing? >> > > The fact that you can have an object property without a colon and a > function without a function keyword. > ES6 concise methods will make this the norm: let o = { m

Re: nested destructuring of undefined and default parameters

2013-02-05 Thread Aaron Frost
my apologies for not reading that ahead of time. I just took the time to read it and must say that I really like this. The syntax is easy to read and offers flexibility. Kudos to all who contrib'd to this. AF On Tue, Feb 5, 2013 at 7:50 AM, Andreas Rossberg wrote: > On 5 February 2013 14:32, A

Re: On notification proxies

2013-02-05 Thread David Bruant
Le 05/02/2013 13:52, Sam Tobin-Hochstadt a écrit : On Tue, Feb 5, 2013 at 7:03 AM, David Bruant wrote: I like the current API better because it allows for a cleaner pairing of pre and post-traps, including the ability to share private intermediate state through closure capture. I have to admit

Re: nested destructuring of undefined and default parameters

2013-02-05 Thread Andreas Rossberg
On 5 February 2013 14:32, Aaron Frost wrote: > I am trying to understand what should happen if you do a nested > destructuring of undefined, where the pattern has a default value included. > Here is an example of my question: > > var foo = { bar : { baz : true } }; > function readFoo({ bar: { baz=

nested destructuring of undefined and default parameters

2013-02-05 Thread Aaron Frost
I am trying to understand what should happen if you do a nested destructuring of undefined, where the pattern has a default value included. Here is an example of my question: var foo = { bar : { baz : true } }; function readFoo({ bar: { baz="DEFAULT BAZ"} }){ console.log(baz); } readFoo(foo);

On notification proxies

2013-02-05 Thread Sam Tobin-Hochstadt
On Tue, Feb 5, 2013 at 7:03 AM, David Bruant wrote: > > > I like the current API better because it allows for a cleaner pairing of pre > > and post-traps, including the ability to share private intermediate state > > through closure capture. > > I have to admit, I'm a bit sad to loose that too. Bu

Re: Action proxies

2013-02-05 Thread David Bruant
Le 04/02/2013 23:11, Brendan Eich a écrit : Mark S. Miller wrote: In any case, you may be right that this is a fatal flaw. You're making a performance-based argument, and it is certainly premature one way or the other to predict how these relative costs will balance out. Let's wait till we hav

Re: Action proxies

2013-02-05 Thread David Bruant
Le 05/02/2013 12:20, Tom Van Cutsem a écrit : 2013/2/4 David Bruant mailto:bruan...@gmail.com>> Le 04/02/2013 22:41, David Bruant a écrit : Le 04/02/2013 19:57, Tom Van Cutsem a écrit : The post-trap could be cached and reused, but only if the post-processin

Re: Proxying Native Objects: Use case

2013-02-05 Thread Tom Van Cutsem
2013/2/4 François REMY > > I don't know if native objects have a mutable [[Prototype]] (by > > assigning __proto__) but if they do, then one solution might be to have > > your native objects inherit from a proxy. The proxy should then be able > > to intercept all missing properties, as I once > >

Re: Action proxies

2013-02-05 Thread Tom Van Cutsem
2013/2/4 David Bruant > Le 04/02/2013 22:41, David Bruant a écrit : > > Le 04/02/2013 19:57, Tom Van Cutsem a écrit : >> >>> The post-trap could be cached and reused, but only if the >>> post-processing is independent of the specific arguments passed to the >>> intercepted operation. >>> >> Is t

Re: How can a lexer decide a token to be "get", "IdentifierName" or "Identifier" ?

2013-02-05 Thread gaz Heyes
On 4 February 2013 23:44, Brendan Eich wrote: > What's confusing? > The fact that you can have an object property without a colon and a function without a function keyword. Then a property descriptor uses a completely new syntax to define the same thing. Why? Object.defineProperty(window,'x',{se