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

What’s New in ES2019

blog.tildeloop.com

Post reply on HN
Print view View original

61–70 of 411 posts

Re: What’s New in ES2019

#61

Post by wongarsu »

jacobwilliamroy wrote: post #22
wongarsu wrote: post #7

Earlier quoted context omitted.

Mutation is a real weakness of Javascript. I think the general idea is "methods don't mutate unless they are ancient". For example Array.map (an IE9-era feature) doesn't mutate, Array.sort (an IE5.5-era feature) does. Similarly a "for(let i=0; i Proper immutable support (or a stronger concept of const) would also help with this.

> for(let e of arr) e = b Is that just arr.map( e => b ) ?

It doesn't do anything and was my attempt to give a simple example that is somewhat obvious while glossing over the complexity

    let arr = [{a: 1, b: ["a", "b"]}, {a: 9, b: ["a","c"]}];
    let b = "!"

    for(let e of arr) e = b;
    console.log(arr)
[{a: 1, b: ["a", "b"]}, {a: 9, b: ["a","c"]}] (unmodified)

    for(let e of arr) e.a = 2;
    console.log(arr)
[{a: 2, b: ["a", "b"]}, {a: 2, b: ["a","c"]}] (modified)

    for(let e of arr) {let copy = {...e}; copy.a = 4;}
    console.log(arr)
[{a: 2, b: ["a", "b"]}, {a: 2, b: ["a","c"]}] (unmodified)

    for(let e of arr) {let copy = {...e}; copy.b[0] = "!";}
    console.log(arr)
[{a: 2, b: ["!", "b"]}, {a: 2, b: ["!","c"]}] (modified)

The most frustrating thing about all of this is that the best way to make a deep copy to avoid all unwanted modification is JSON.parse(JSON.stringify(arr))

Re: What’s New in ES2019

#62

Post by namelosw »

Finally, flatMap is here.

I really hope there could be syntactic sugar like do expression in Haskell, for in Scala, and LinQ in C# for flatMap instead of type limited version like async await.

Another thing is pipe operator seems to be very welcome among the proposals. There will be no awkward .pipe(map(f), tap(g)) in RxJS since then.

Re: What’s New in ES2019

#63

Post by chriswwweb »

cypressious wrote: post #53
halfmatthalfcat wrote: post #47

Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things. [1] https://github.com/tc39/proposal-pattern-matching [2] https://github.com/tc39/proposal-optional-chaining

Optional chaining recently reached stage 3, the babel plugin is available and TS is going to adopt it for 3.7.0.

Oh I didnt know about TS being so close to have it, that's great news

EDIT: here is the confirmation TS 3.7.0 got tagged: https://github.com/microsoft/TypeScript/issues/16#issuecomme...

EDIT 2: wow just noticed, that the issue ID is "16" and it has been open since Jul 15, 2014 (I guess: good things take time ... ;) )

Re: What’s New in ES2019

#64

Post by johnkpaul »

cypressious wrote: post #53
halfmatthalfcat wrote: post #47

Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things. [1] https://github.com/tc39/proposal-pattern-matching [2] https://github.com/tc39/proposal-optional-chaining

Optional chaining recently reached stage 3, the babel plugin is available and TS is going to adopt it for 3.7.0.

This is awesome and hopefully 2020 bound. The only thing I remember from my few months of looking into Groovy was the "elvis operator" and being very jealous of it.

Re: What’s New in ES2019

#68

Post by phpnode »

halfmatthalfcat wrote: post #47

Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things. [1] https://github.com/tc39/proposal-pattern-matching [2] https://github.com/tc39/proposal-optional-chaining

Pattern matching is a really important feature but I strongly dislike that proposal because it feels like it introduces a bunch of single purpose syntax that's going to restrict the ability to evolve the language in future. It feels like it's an addon, not a holistic solution.

I would much, much rather that type annotation syntax gets standardised first, because it is comparatively easy to build pattern matching when that's in place but going the opposite direction is difficult. What is a type if not a pattern?

Re: What’s New in ES2019

#69

Post by __ryan__ »

heavenlyblue wrote: post #21
afandian wrote: post #3

It's great to see JS getting some of the features of better planned languages. But I'm still very nervous about some of the stuff mentioned here with regard to mutation. Taking Rust and Clojure as references, you always know for sure whether or not a call to e.g. `flat` will result in a mutation. In JS, because of past experience, I'd never be completely confident that I wasn't mutating something by mistake. I don't…

I still don't understand why neither JSs var or let allow you to redefine the variable with the same name. I makes chaining things while debugging so much harder: let a = a.project(); let a = debug(a); let a = a.eject(); vs let a1 = a.project(); let a1d = debug(a1); let a2 = a1d.eject();

    let a = a.project();
    a = debug(a)
    a = a.eject();
This is perfectly legal.

Re: What’s New in ES2019

#70

Post by Izkata »

wongarsu wrote: post #61
jacobwilliamroy wrote: post #22

Earlier quoted context omitted.

> for(let e of arr) e = b Is that just arr.map( e => b ) ?

It doesn't do anything and was my attempt to give a simple example that is somewhat obvious while glossing over the complexity let arr = [{a: 1, b: ["a", "b"]}, {a: 9, b: ["a","c"]}]; let b = "!" for(let e of arr) e = b; console.log(arr) [{a: 1, b: ["a", "b"]}, {a: 9, b: ["a","c"]}] (unmodified) for(let e of arr) e.a = 2; console.log(arr) [{a: 2, b: ["a", "b"]}, {a: 2, b: ["a","c"]}] (modified) for(let e of arr) {let…

...honestly, I don't see much complexity here. Understanding of reference types and the difference between deep copy and shallow copy makes it pretty straightforward - the result is the same as it would be in python or java.
Post reply on HN