Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECMAScript 2018 Language Specification

tc39.github.io

Post reply on HN
Print view View original

31–40 of 49 posts

Re: ECMAScript 2018 Language Specification

#31

Post by bterlson »

growtofill wrote: post #4

According to [the repo]( https://github.com/tc39/proposals/blob/master/finished-propo... ) only one minor feature had reached stage 4 since last year. Not sure why this is on top HN.

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 :)

Re: ECMAScript 2018 Language Specification

#32

Post by bterlson »

sterlingfs wrote: post #22

Im honestly not trying to be like TLDR, but a revision log would be immensely appreciated.

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.

Re: ECMAScript 2018 Language Specification

#33

Post by bterlson »

pc2g4d wrote: post #25

This page is confusing because it describes itself as ECMAScript 2018 but the features it lists are those I've associated with ECMAScript 2017. Looking at the Github repo, you can see that they changed it from 2017 to 2018 on March 31st: https://github.com/tc39/ecma262/commit/8340bf9a8427ea81bb0d1... So what happened to 2017?

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.

Re: ECMAScript 2018 Language Specification

#34

Post by bterlson »

nikcub wrote: 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...

If anyone has any data on this topic I would love to hear and understand it!

Re: ECMAScript 2018 Language Specification

#35

Post by bterlson »

allenwb wrote: post #12

That document is an incomplete working DRAFT for the next edition of the ECMAScript standard. Don't assume that the current snapshot is feature complete.

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).

Re: ECMAScript 2018 Language Specification

#36

Post by acdha »

nikcub wrote: 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?

Re: ECMAScript 2018 Language Specification

#37

Post by johnsonjo »

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!

[1]: https://github.com/tc39/proposal-async-iteration [2]: https://github.com/tc39/agendas/blob/master/2017/11.md

Re: ECMAScript 2018 Language Specification

#38

Post by javajosh »

sandstrom wrote: post #26

I hoped decorators[1] would make it, but seems unlikely (looks like they're still at stage 2). [1] https://github.com/tc39/proposal-unified-class-features

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.

Re: ECMAScript 2018 Language Specification

#39

Post by always_good »

javajosh wrote: post #38
sandstrom wrote: post #26

I hoped decorators[1] would make it, but seems unlikely (looks like they're still at stage 2). [1] https://github.com/tc39/proposal-unified-class-features

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

They're talking about this section in particular: https://github.com/tc39/proposal-unified-class-features#deco...

Where decorators are sugar for higher order functions, even capable of `Class -> Class` transformation, which makes them much different from Java annotations.

Post reply on HN