Live data from Hacker News

ECMAScript 2018 Language Specification

tc39.github.io

41–49 of 49 posts

Re: ECMAScript 2018 Language Specification

#41

From section “4. Overview” ECMAScript is an object-oriented programming language for ... heavy sigh

As opposed to what?

Prototype-based is a form of OOP: https://en.wikipedia.org/wiki/Prototype-based_programming

And "functional programming language" would be way too fine a point, like calling Ruby an FP language.

Re: ECMAScript 2018 Language Specification

#42

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 ES20…

Async iterators will be cool.

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.

Re: ECMAScript 2018 Language Specification

#43
post #36
post #17

Optional catch binding[0], which is at stage 3, seems like a bad idea[1] and has been pointed out as such[2] [0] http://2ality.com/2017/08/optional-catch-binding.html [1] http://wiki.c2.com/?EmptyCatchClause [2] https://github.com/tc39/proposal-optional-catch-binding/issu...

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?

That's true, but in that case adding optional catch binding is completely useless.

Re: ECMAScript 2018 Language Specification

#44

From section “4. Overview” ECMAScript is an object-oriented programming language for ... heavy sigh

As opposed to what? Prototype-based is a form of OOP: https://en.wikipedia.org/wiki/Prototype-based_programming And "functional programming language" would be way too fine a point, like calling Ruby an FP language.

Multi-paradigm

Re: ECMAScript 2018 Language Specification

#45
post #9

Earlier quoted context omitted.

Suppose I wanted to embed your solution itself into a template literal. It would look like this: `${'`'}Look, this is a backtick: \${'${'`'}'}${'`'}`

Rust has a nice solution to this. 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.

just blue my mind. is there a babel plugin that will let me do this?

Re: ECMAScript 2018 Language Specification

#46
post #36
post #17

Optional catch binding[0], which is at stage 3, seems like a bad idea[1] and has been pointed out as such[2] [0] http://2ality.com/2017/08/optional-catch-binding.html [1] http://wiki.c2.com/?EmptyCatchClause [2] https://github.com/tc39/proposal-optional-catch-binding/issu...

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

Re: ECMAScript 2018 Language Specification

#48

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 ES20…

Async iterators will be cool. 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...

Re: ECMAScript 2018 Language Specification

#49
post #5

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.) [1] ht…

you can escape backticks with \
Post reply on HN