Re: @@isConcatSpreadable
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 as a property key anywhere in the spec. Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@isConcatSpreadable
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 property key anywhere in the spec. Thanks! Axel Look at the IsConcatSpreadable abstract operation: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-isconcatspreadable Note that, in absence of @@isConcatSpreadable property key, IsArray() is considered instead, so that builtin objects and constructors defined in the spec do not need to use @@isConcatSpreadable in order to get the right semantics. —Claude___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Look-behind proposal
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] https://mail.mozilla.org/pipermail/es-discuss/2013-September/033837.html On 21 May 2015 at 14:01, Nozomu Katō noz...@akenotsuki.com wrote: I revised my proposal for lookbehinds: http://www.akenotsuki.com/misc/srell/lookbehind_proposal.html I rewrote the paragraphs about how to count Atoms in Disjunction, to clarify that the recursive call is used for nested Disjunctions. Regards, Nozomu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: When should we define a function as async
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 actively persued (Jafar, feel free to correct me here). If you want to return a promise and attach callbacks to it (not returning promise that spawns by then), you should not use async This is also correct. it’s quite hard to determines if one method is actual async (with Promise) or sync (immediately return values), so I may preferr to mark all async function async for better read experience I don't think the distinction is correct. For the consumer - it is irrelevant if a function is async or just returns a promise. If you're writing an API and your function _sometimes_ return promises it is best to make them always return promises - more generally if a function is sometimes asynchronous (with callbacks too) it should always be asynchronous. Never write return await xxx;, it seems useless either xxx is a promise or not Yes, unless of course you're also doing other things inside the function. Anyway this is not an issue about spec itself, it’s more like an open discussion, thanks for reply :) Correct - I'm in no position to tell you what you can and cannot do but in the future I think it is best to ask these questions in Stack Overflow, IRC and on discussion groups. If you have issues about style, usage or anything else that is not the spec it is best to keep them off esdiscuss which is quite a noisy list anyway :) Feel free to send me an email (rather than the whole list) if you have other issues with `async` that are not spec related. Cheers. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential Operator / Null Propagation Operator
@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 double character, but `.?` could also work, and perhaps be easier to read (`??` is a bit heavy on the eye with two big glyphs). The only confusion that could happen (AFAICS) is when mixing the decimal point with the ternary operator. But the spec already states that a digit followed by a point is always a decimal point (which is why we need to do `(255).toString(2)`). So the parser only has to look very locally to find the correct interpretation. And it helps humans too. @Brendan: yes, soaking up all null/undefined values will probably be wanted by some. But personally, I'd prefer to show in my code where exactly null values can be expected, and where stuff should always be defined. Using the null-soaking syntax too much might result in code that's hard to debug (some null is coming from somewhere, but nobody has an idea from where, as it's just propagating through all accessors). Thanks for all your comments. Regards, Sander 2015-06-02 20:30 GMT+02:00 Brendan Eich bren...@mozilla.org: Sam Ruby wrote: I think that the problem here isn't that it is ambiguous, it is that it isn't obvious. Fair point! Something that might be more obvious but requires an additional character: `orders.?[client.key].price`. That's not bad. The whole proposal may founder, though, on grawlix objections. And some still want the ?obj.foo.bar to soak null/undefined obj and missing foo or null/undefined value of foo. CoffeeScript fans for sure, but it's in principle and practice at least as valid a use-case as obj.?foo is. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
@@isConcatSpreadable
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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: @@isConcatSpreadable
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 the Array#concat() behaviour a little cleaner, in my opinion. Unless, perhaps, the point was to leave it open and allow the end-user to monkey-patch it to false, thus finally fixing Array#concat() after all these years...? Was that the plan? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@isConcatSpreadable
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 [22.1.3.11](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-isconcatspreadable). Would've made the Array#concat() behaviour a little cleaner, in my opinion. Given that inheriting from `Array.prototype` and being an Array object are two distinct notions, that would be a breaking change from the past that needs careful consideration. —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: When should we define a function as async
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 callbacks to it (not returning
promise that spawns by then), you should not use async
function foo() {
var waiting = fetchResource();
// Since this code you should not use async functions
waiting.then(logMessage);
return waiting;
}
After all above cases, it is still OK to use none async functions that returns
Promise, but it’s quite hard to determines if one method is actual async (with
Promise) or sync (immediately return values), so I may preferr to mark all
async function async for better read experience
Never write return await xxx;, it seems useless either xxx is a promise or not
Anyway this is not an issue about spec itself, it’s more like an open
discussion, thanks for reply :)
Best regards
Gray Zhang
在 2015年6月3日 下午4:18:14, Gruenaum Benjamin (benjami...@gmail.com) 写到:
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 to promise, should it become an
async function and use await in all possible cases to eliminate then calls?
No, it's possible to have legitimate use cases where this is not the case, for
example:
```js
async function foo() { ...} // queries an API
async function bar() { ... } // queries an API
function fooBar() {
return Promise.all([foo(), bar()]);
}
```
It's a contrived simplified example but the point is you might have functions
that work on promises that should not themselves be `async`.
For example, in your updateUser function, you can remove `async` and `await`
and get the same value (as you observed in growUp1).
To clarify, there is no _semantic_ distinction in your examples between an
async function and a regular function that returns a promise - it's just syntax
sugar - just like generators and regular functions that return iterables.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: When should we define a function as async
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 to promise, should
it become an async function and use await in all possible cases to
eliminate then calls?
No, it's possible to have legitimate use cases where this is not the case,
for example:
```js
async function foo() { ...} // queries an API
async function bar() { ... } // queries an API
function fooBar() {
return Promise.all([foo(), bar()]);
}
```
It's a contrived simplified example but the point is you might have
functions that work on promises that should not themselves be `async`.
For example, in your updateUser function, you can remove `async` and
`await` and get the same value (as you observed in growUp1).
To clarify, there is no _semantic_ distinction in your examples between an
async function and a regular function that returns a promise - it's just
syntax sugar - just like generators and regular functions that return
iterables.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promise sub-class: super((resolve, reject) = this) ?
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 thrown since the `this` binding has not yet been
initialized?
Transpilers however have elected to prevent this to err on the side of
ensuring that invalid ES6 allowed through because adding runtime checking for
the `this` binding would be difficult?
In other words, transpilers have elected to be buggy. ECMAScxript 2015 does
not given implementations an option in this regard. If an implementation
produces such an early error it is not in compliance with the standard.
It doesn't seem like it should be very hard for transpilers to correctly
implement the derived constructor this-TDZ semantics. For example, here is a
plausible strategy:
1) As a prologue to each constructor body defined in a class definition that
includes an extends clause emit:
```js
let $$thisAlive = false;
let $$this = ()= { if ($$thisAlive) then return this; else throw
ReferenceErrorthis referenced before super call completes)};
let $$superCalled = r= $$thisAlive = true, r;
```
2) compile ever reference to `this` within such constructors as `$$this()`;
3) wrap every call to the super constructor within such constructors as:
`$$superCalled(the emitted code to make the call)`
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promise sub-class: super((resolve, reject) = this) ?
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` it has not finished running yet. Of course, the workaround as domenic has pointed is to extract `resolve` and `reject` from the `super` call since it is synchronous. (also I'm assuming you're not really mapping `(resolve, reject)` to `this`? `this` is an object and the promise constructor ignores return values anyway, you might as well pass a no-op in.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: @@isConcatSpreadable
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 [22.1.3.11](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-isconcatspreadable). Would've made the Array#concat() behaviour a little cleaner, in my opinion. Unless, perhaps, the point was to leave it open and allow the end-user to monkey-patch it to false, thus finally fixing Array#concat() after all these years...? Was that the plan? Exactly! ES6 has to preserve the previous semantics for all existing programs, including programs that attempted to create Array subclasses in various ad hoc manners. @@isConcatSpreadable exists to allow new ES6-level array subclasses to explicitly opt-out of the legacy implicit spread behavior of concat. Allen. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise sub-class: super((resolve, reject) = this) ?
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 starting off by claiming the restriction on this before super() makes perfect sense, let's be honest that lots of normal developers will be tripped up by this restriction. this is used a reference throughout class code: it makes perfect sense to use it in a constructor. Passing extended-class-specific values to super() is exactly what super() does. Thus using this in a constructor before calling super() is entirely natural in light of other experience with the language. Our inability to support this before super() is unfortunate, so let's sympathize and encourage people to understand. I think that the crux is that the promise constructor runs _synchronously_ so when you pass it `this` it has not finished running yet. Of course, the workaround as domenic has pointed is to extract `resolve` and `reject` from the `super` call since it is synchronous. (also I'm assuming you're not really mapping `(resolve, reject)` to `this`? `this` is an object and the promise constructor ignores return values anyway, you might as well pass a no-op in.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise sub-class: super((resolve, reject) = this) ?
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 intentions I must say that you are overreacting. The
subject-line code (h/t Mark Miller for pointing me at it!) in context of
the superclass constructor uses `this` before `super` has returned. That's
a no-no for pretty-good reason.
If you have a better alternative design, we needed it last month. As
things stand, this is a thing to learn, with a workaround. What's the big
deal?
/be
Matthew Robb wrote:
If I thought I could make any money then I would most definitely bet that
the changes made to classes that are at the root of this problem will be
the undoing of es classes and I find myself feeling more and more like
avoiding them is the easiest thing to do.
This use-case is a perfect example of something that is EXTREMELY
unexpected which is funny because the changes are supposed to be supporting
subclassing of built-ins.
Very disheartened :(
- Matthew Robb
On Tue, Jun 2, 2015 at 6:43 PM, Domenic Denicola d...@domenic.me mailto:
d...@domenic.me wrote:
Hmm I am pretty sure Babel et al. are correct here in not allowing
this. The super call needs to *finish* before you can use `this`.
Chrome also works this way.
The correct workaround is
```js
let resolve, reject;
super((a, b) = {
resolve = a;
reject = b;
});
// use this
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
