I'm really hoping async iterators [1] will make it to stage 4, but from the github I can't really tell what's holding it back as it has several browsers with implementation (I know that's not the only requirement for stage 4, but it's one of them.) I also noticed it's not on the agenda for the November meeting [2]. I understand there are a lot of features being worked on concurrently so it may not be finished by ES2018, but is there any chance someone could give me an update on what's happening with it. I just think this feature is amazing! And also thanks TC39 for all the great features coming to ECMAScript!
Since Java blocks, you can implement a crawler as a custom iterator that makes API requests / paginates behind the scenes and thus abstracts away the fact that it's making a series of requests since the callsite just iterates over the values as it finds them.
Would be nice to have that sort of abstraction in Node.
> you can implement a crawler as a custom iterator that makes API requests / paginates behind the scenes and thus abstracts away the fact that it's making a series of requests since the callsite just iterates over the values as it finds them.
Yep, that's what I had built when they were announced. I had an API that returned a page and "next" pointer but the iterator just returned next item (promise) and followed next links, for the API consumer it looked like a regular collection. Pretty nice!
> Would be nice to have that sort of abstraction in Node.
Unfortunately Node APIs will probably always lag behind because it's hard to rewrite everything using Promises...
This specification introduces Async Functions, Shared Memory, and Atomics along with smaller language and library enhancements, bug fixes, and editorial updates. Async functions improve the asynchronous programming experience by providing syntax for promise-returning functions. Shared Memory and Atomics introduce a new memory model that allows multi-agent programs to communicate using atomic operations that ensure a well-defined execution order even on parallel CPUs. This specification also includes new static methods on Object: Object.values, Object.entries, and Object.getOwnPropertyDescriptors.
The github issue seems to cover this well: existing linters have code to cover intentionally unused bindings and this is a cleaner way to express that. Do you disagree with the rationale in that discussion?
I'd be more ok with it being paired with exception filtering (or what Netscape called conditional catch clauses), ie.
} catch (e if e instanceof CriticalError) {
// handle critical
} catch (e if e instanceof TypeError) {
// handle type mismatch
} catch () {
}
so you could at least handle critical and other errors before blindly silencing - but for some reason exception filtering/conditional catch hasn't come up in ECMA
Official standards are moved to ECMA's website. E.g. ES2017 is here: https://www.ecma-international.org/publications/files/ECMA-S.... The GitHub site is mostly targeted toward implementers who are always working off the latest draft for new spec or implementation work.
Template Literal Revision [1] is a welcome change, but still falls way short, as there's still no way to easily include the backtick itself inside raw text.
I wish ES would adopt python-style triple-quotes, so you could do things like:
String.raw```Look, this is a backtick: "`"```
(The inability to do this is a pain point when you want to embed a language in ES and that language itself makes use of backticks.)
r"foo" == "foo" // r" means the literal ends at "
r#""foo""# == "\"foo\"" // r#" means the literal ends at "#
r##"r#""foo""#"## == "r#\"\"foo\"\"#" // r##" means the literal ends at "##
and so on.
Basically you add as many # outside as necessary to distinguish the end of the literal (double-quote followed by some #) from any such sequence in the middle of the literal.
Didn't even know that was on the docket, that's awesome. Would doing operations on them automatically cast them to float64? I know they offer integer typed arrays, but any mathematical operations will automatically cast them to float64, which is a bummer.
More strongly, the draft is incomplete by its very nature. If you care about having only complete and ratified standards, do not use the GitHub snapshot. Use the official versions hosted on ECMA's website (https://www.ecma-international.org/memento/TC39-M.htm).
I wish the spec included a more bullet pointy changelog from the previous version, but at least it has this paragraph:
This specification introduces Async Functions, Shared Memory,
and Atomics along with smaller language and library
enhancements, bug fixes, and editorial updates. Async
functions improve the asynchronous programming experience by
providing syntax for promise-returning functions. Shared
Memory and Atomics introduce a new memory model that allows
multi-agent programs to communicate using atomic operations
that ensure a well-defined execution order even on parallel
CPUs. This specification also includes new static methods on
Object: Object.values, Object.entries, and
Object.getOwnPropertyDescriptors.
Having spent a long time with Java I believe I understand the limits of this style of coding; in my considered opinion, composition is almost always better than inheritance. This is true regardless of the type of inheritance, be it prototypal or class-based (in appearance or reality). Therefore, adding features to JS to make class-like inheritance slightly better is not a trade-off I would make, favoring a simpler language over a feature who's use shouldn't be encouraged.
Where decorators are sugar for higher order functions, even capable of `Class -> Class` transformation, which makes them much different from Java annotations.
I hear ya. Once the spec is finalized for the year I produce a change log. I have done so in between versions before but things tend to be menial and/or change a lot and it was a lot of work for not too much gain. Willing to go back on this. You can always watch the commits go in here though: https://github.com/tc39/ecma262/commits/master.
There are many proposals sitting at the cusp of the stage 3 to stage 4 transition. There will be a couple more meaty things to make it. I suspect we'll end up with more proposals ready than I have time to integrate into the main spec :)
My number 1 wish for JavaScript is that it could become fully expression oriented. There's been talk about `do` blocks, which would modify control structures like `if` to become expressions but I don't think that's gone anywhere.
[1]: https://github.com/tc39/proposal-async-iteration [2]: https://github.com/tc39/agendas/blob/master/2017/11.md