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
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
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
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
>
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
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
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
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
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
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=
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 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
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
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
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
> >
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
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
17 matches
Mail list logo