Re: @@isConcatSpreadable

2015-06-03 Thread Tom Schuster
It's meant as an extension point. I believe some DOM list/array is supposed to use this. On Wed, Jun 3, 2015 at 11:08 AM, Axel Rauschmayer a...@rauschma.de wrote: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.concat I’m not seeing @@isConcatSpreadable being used

Re: @@isConcatSpreadable

2015-06-03 Thread Claude Pache
Le 3 juin 2015 à 11:08, Axel Rauschmayer a...@rauschma.de a écrit : https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.concat https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.concat I’m not seeing @@isConcatSpreadable being used as a

Re: Look-behind proposal

2015-06-03 Thread Sebastian Zartner
Thank you for picking this up again! I asked for adding look-behinds back in 2013[1], though I didn't find the time to come up with an algorithm and read into writing this down for the specification. So let's hope this discussion will result in something this time. Sebastian [1]

Re: When should we define a function as async

2015-06-03 Thread Benjamin Gruenaum
If you want a special Promise (subclass or extended), you should not use async function since it casts the return value to a standard Promise Right, there was a proposal that let you override how await works ( https://github.com/jhusain/compositional-functions) but I don't think it's currently

Re: Existential Operator / Null Propagation Operator

2015-06-03 Thread Sander Deryckere
@Sam Ruby: I think we should indeed go for an extra character. In the proposals that result in `?[` and similar, it may be possible to define correctly in the spec, but it would indeed be non-obvious for humans to interprete, and potentially make the parser slower. I proposed `??` as a unique

@@isConcatSpreadable

2015-06-03 Thread Axel Rauschmayer
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.concat I’m not seeing @@isConcatSpreadable being used as a property key anywhere in the spec. Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___

Re: Re: @@isConcatSpreadable

2015-06-03 Thread Leon Arnott
This reminds me: I feel like the spec should've added Array.prototype[Symbol.isConcatSpreadable] (value:true, configurable:false, writable:false), and eliminated the final IsArray() test from [22.1.3.11](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-isconcatspreadable). Would've made

Re: @@isConcatSpreadable

2015-06-03 Thread Claude Pache
Le 3 juin 2015 à 12:46, Leon Arnott leonarn...@gmail.com a écrit : This reminds me: I feel like the spec should've added Array.prototype[Symbol.isConcatSpreadable] (value:true, configurable:false, writable:false), and eliminated the final IsArray() test from

Re: When should we define a function as async

2015-06-03 Thread Gray Zhang
This is possibly a code style related question, I studied a little deeper so this is how I currently learned: If you want a special Promise (subclass or extended), you should not use async function since it casts the return value to a standard Promise If you want to return a promise and attach

Re: When should we define a function as async

2015-06-03 Thread Benjamin Gruenaum
A function needs to be defined `async` if you intend to possibly use the await keyword inside it. If a function is returning Promise, it MUST be async If a function depends on an async function, it **MUST be async A further question could be, if one function only contains some simple then calls

Re: Promise sub-class: super((resolve, reject) = this) ?

2015-06-03 Thread Allen Wirfs-Brock
On Jun 2, 2015, at 8:08 PM, Logan Smyth wrote: To clarify things, since I don't think it's been made abundantly clear, the example that Sebastian gave would work in a standard ES6 environment, correct? It is only if the callback were executed synchronously that the exception would be

Re: Promise sub-class: super((resolve, reject) = this) ?

2015-06-03 Thread Benjamin Gruenaum
Am I missing something obvious in `super((resolve, reject) = this)` ? First of all, it makes perfect sense for `this` not work work before super has been called - and it has not been called yet. I think that the crux is that the promise constructor runs _synchronously_ so when you pass it `this`

Re: @@isConcatSpreadable

2015-06-03 Thread Allen Wirfs-Brock
On Jun 3, 2015, at 3:46 AM, Leon Arnott wrote: This reminds me: I feel like the spec should've added Array.prototype[Symbol.isConcatSpreadable] (value:true, configurable:false, writable:false), and eliminated the final IsArray() test from

Re: Promise sub-class: super((resolve, reject) = this) ?

2015-06-03 Thread John Barton
On Wed, Jun 3, 2015 at 1:27 AM, Benjamin Gruenaum benjami...@gmail.com wrote: Am I missing something obvious in `super((resolve, reject) = this)` ? First of all, it makes perfect sense for `this` not work work before super has been called - and it has not been called yet. Rather than

Re: Promise sub-class: super((resolve, reject) = this) ?

2015-06-03 Thread Matthew Robb
It seems like, at least in the case with Promise, it could be solved also by having the this binding of the executor bound to the promise or have the promise object passed into the executor as a third argument maybe? On Jun 2, 2015 10:38 PM, Brendan Eich bren...@mozilla.org wrote: With best