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

81–90 of 411 posts

Re: What’s New in ES2019

#81

Post by rpeden »

heavenlyblue wrote: post #73
__ryan__ wrote: post #69

Earlier quoted context omitted.

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

So what's the point of having let, then?

let declares a block-scoped variable, while var declares a function-scoped variable.

Limiting a variable's scope can help avoid subtle and potentially annoying errors. For example, if you use a let variable inside an if block, it'll only be accessible by code inside the block. If you use var inside an if block, your variable will be visible to the entire function.

Re: What’s New in ES2019

#82

Post by jacobwilliamroy »

heavenlyblue wrote: post #51
shortercode wrote: post #46

Earlier quoted context omitted.

I always assumed it was to protect against: accidental naming errors, confusion of what a declaration is and copy/paste issues. When I first started writing rust and saw it was a thing I thought it was a terrible idea. I'm a more open towards it now, the strong static analysis Rust does help and it can improve code quality if used in small amounts. However, it still can be quite confusing. Given that JS doesn't restr…

>> However, it still can be quite confusing. I don't know - it's never confusing to me. I just use the IDE that allows me to view the types of the variables whenever I need to see them. IDE also highlights the definitions and then the usages of the variable, including the syntax scope where it's used. You're definitely using the wrong tools for the job if you get confused with that little detail. >> Given that JS doe…

var and let tell the compiler the scope in which it should declare the variable (oversimplifying). If var or let are not present, the variable is declared in the global scope; unless you're in strict-mode, then you get a scolding.

So var and let are only tangential to the whole declaration process and only indicate the scope in which the variable is bound.

I feel confused. Why do you want your assignment statements to be prefixed with var's and let's?

Re: What’s New in ES2019

#83

Post by underwater »

alexlur wrote: post #35

That Function.prototype.toString change is probably going to break some Angular.js code who relies on scanning function argument names for dependency injection.

TC39 have been fairly conservative about not breaking real world code. Array.prorotype.flat was named flat and not flatten because of compatibility issues with old versions of MooTools.

Re: What’s New in ES2019

#84

Post by masklinn »

ahmedfromtunis wrote: post #66

Can someone please point me to the rationale behind the new toString() function?

Rather than how complete it is, the real improvements of the proposal are:

1. it all but requires that ES-defined functions stringify to their source code. Pre-ES2019 that's implementation-defined

2. it standardises the placeholder for the case where toString can't or won't create ECMAScript code (e.g. host functions), this could otherwise be an issue as with implementation-defined placeholders subsequent updates to the standard might make the placeholder unexpectedly syntactically valid, by having the placeholder standard future proposals can easily avoid making it valid

3. the stringification should be cross-platform as the algorithm is standardised

Re: What’s New in ES2019

#85

Post by nullandvoid »

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

Providing It was syntactically correct the first call would assign e to a variable b for each iteration ( pretty pointless )

The arr.map providing you had a variable on the left side would output the result of each iteration into said array ( so an array containing all b values - however I guess you meant arr.map(e => e)

Re: What’s New in ES2019

#86

Post by heavenlyblue »

rpeden wrote: post #81
heavenlyblue wrote: post #73

Earlier quoted context omitted.

So what's the point of having let, then?

let declares a block-scoped variable, while var declares a function-scoped variable. Limiting a variable's scope can help avoid subtle and potentially annoying errors. For example, if you use a let variable inside an if block, it'll only be accessible by code inside the block. If you use var inside an if block, your variable will be visible to the entire function.

The truth is that if you need to declare a variable outside your current scope you should probably declare it in the outside scope in the first place.

In the scenario with var/let I need to grok the code in order to tell which variables are visible in my current scope.

Re: What’s New in ES2019

#87

Post by wongarsu »

Izkata wrote: post #70
wongarsu wrote: post #61

Earlier quoted context omitted.

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.

I don't think Python or Java are examples of good or simple behavior here. Java at least has a strong culture of "copy everything or make it immutable at class boundaries" while javascript libraries often leave you guessing.

Examples where this is easy are C where every copy and allocation is very explicit, C++ which has a good `const` concept that's actually useful, or Rust with it's ownership concept that makes mutability very obvious.

Re: What’s New in ES2019

#88

Post by swish_bob »

2T1Qka0rEiPr wrote: post #5
ajanuary wrote: post #4

Earlier quoted context omitted.

Doesn't the fact that flatten by default only flattens one level mean you can still create nested output by emitted nested outputs?

Yes, it appears so. From MDN: > The flatMap() method first maps each element using a mapping function, then flattens the result into a new array. It is identical to a map() followed by a flat() of depth 1, but flatMap() is often quite useful, as merging both into one method is slightly more efficient. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

FlatMap is often most useful when recursing, in my experience.

Re: What’s New in ES2019

#89

Post by jacobwilliamroy »

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 really like the lisp convention of using !'s to indicate mutation. Like set-car! .

In javascript you kind of have to reason backwards and declare your variables as immutable (const). Though there are still some bugaboos; object fields can still be overwritten even if the object was declared with const.

Re: What’s New in ES2019

#90

Post by wongarsu »

nullandvoid wrote: post #85
jacobwilliamroy wrote: post #22

Earlier quoted context omitted.

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

Providing It was syntactically correct the first call would assign e to a variable b for each iteration ( pretty pointless ) The arr.map providing you had a variable on the left side would output the result of each iteration into said array ( so an array containing all b values - however I guess you meant arr.map(e => e)

> Providing It was syntactically correct

Providing arr is iterable (e.g. an array) it's perfectly valid js. Your linter might scream at you to add braces and a semicolon, but neither is needed for correctness here.

Post reply on HN