ES6 Overview in Bullet Points • Hacker News Board

Re: ES6 Overview in Bullet Points

#41

Post by tolmasky » Fri, Nov 27, 2015, 11:46 PM UTC

chrisseaton wrote: post #40

tolmasky wrote: post #39

Earlier quoted context omitted.

If they were iterable, then they couldn't be weak, because you've effectively given an API to reach references unconditionally, thus meaning they are always reachable, thus meaning none of them can ever be GC'ed. for (x of myWeakSet) Now, if you were to say "well, make them weak and make iteration only happen on the items that have no External references", you've now created a really tricky situation where iteration…

> If they were iterable, then they couldn't be weak Of course they can be both weak and iterable. Java's WeakMap does it. > because you've effectively given an API to reach references unconditionally How so? The iteration would only return objects that hadn't been collected. > you've now created a really tricky situation where iteration essentially forces a GC pass because it needs to know whats reachable and what is…

I imagine you are referencing this comment "One could make WeakSet implementations that are iterable, but those can lead to non-deterministic algorithms (depending on GC behaviour) if used in the wrong way, and therefore the ES committee decided not to make the contents available."

I suppose when I said "you've now created a really tricky situation where iteration essentially forces a GC pass because it needs to know whats reachable and what isn't at iteration time", I was directly responding to this behavior: if you have a GC pass before every iteration, it clearly would solve the non-determinism problem, as you would have an iteration that had well-defined behavior. I took it as a given that an iteration that sometimes returns things with no external references and sometimes doesn't would be completely absurd, and thus the GC pass would be required.

If you are telling me that this is precisely how Java's works however, then I guess I should have known better and checked that a language like Java apparently does allow this ... interesting behavior. (I certainly don't know how it works there)

Re: ES6 Overview in Bullet Points

#42

Post by peeters » Fri, Nov 27, 2015, 11:50 PM UTC

ajanuary wrote: post #30

peeters wrote: post #14

> Temporal Dead Zone - Attempts to access or assign to foo within the TDZ (before the let foo statement is reached) result in an error Can anybody explain why "let" variables are hoisted to the start of block given this Temporal Dead Zone exists? Is it an artifact of modern JS runtimes? And given the TDZ what practical benefit does knowing that the variable is technically hoisted provide?

I've never liked the phrase 'variable hoisting'. It implies the compiler actively moves the variable declaration. What's actually happening is lexical scoping - a variable declaration is associated with a lexical scope. For var declarations, the lexical scope is the function, for let declarations, it's the block. When a variable is referenced, it first looks for the variable associated with the lexical scope of the v…

Thanks for the reply...I definitely get the advantage and popularity of lexical scoping. I'm not sure about your claim about every language doing hoisting though; take Java as an example:

    class Example {
      String f = "foo";
 
      void foo() {
        System.out.println(f); //foo
 
        {
          System.out.println(f); //foo
          String f = "bar";
          System.out.println(f); //bar
        }
 
        System.out.println(f); //foo
        String f = "baz";
        System.out.println(f); //baz
      }
    }

I understand that Java doesn't perfectly match var or let, in that the lexical matching of local variables is not the same as either. But Java really doesn't seem to be doing hoisting here, and it's certainly clearer what f refers to before the local variable is declared (though I like the explicit error the TDZ gives the best).

Re: ES6 Overview in Bullet Points

#43

Post by Sir_Cmpwn » Sat, Nov 28, 2015, 12:06 AM UTC

gramakri wrote: post #4

Great writeup. I welcome most of the additions, but I somehow cannot get behind things like: var {foo} = pony is equivalent to var foo = pony.foo var {foo: baz} = pony is equivalent to var baz = pony.foo I am not sure why, but most languages get into a state where they seem to encourage non-readable code. What was wrong with 'var baz = pony.foo' to start with?

    var { email, full_name } = get_user();
    send_email(email, `Hi ${full_name}!`);

Re: ES6 Overview in Bullet Points

#44

Post by _greim_ » Sat, Nov 28, 2015, 2:05 AM UTC

Retra wrote: post #22

aggronn wrote: post #7

Earlier quoted context omitted.

the core use case is var { foo } = pony I agree this is kind of silly in isolation, but more often than not, its used like this: var { foo, bar, baz } = pony which is honestly not that hard to read, and is much better than var foo = pony.foo; var bar = pony.bar; var baz = pony.baz; which is very useful when you're referencing properties of pony a lot. Since you're going to see destructuring used like var { foo, bar,…

It's not hard to read if you already know what it does. As it stands, it's a barrier to learning and a detriment to consistency in style.

> As it stands, it's a barrier to learning and a detriment to consistency in style.

Not true. It's actually super-easy to learn and meshes well with existing variable declaration styles.

Re: ES6 Overview in Bullet Points

#45

Post by _greim_ » Sat, Nov 28, 2015, 2:24 AM UTC

ponyous wrote: post #3

Looking good and informative, but to be honest I am really interested in use cases. I think I understand how to use generators but I have no idea where I could use them in real-world scenarios. Same goes for WeakMaps, Proxies... Anyone care to give some examples?

Too many use cases to list, but generally a nice way to for...of anything, for example a recursive binary tree traversal:

    [Symbol.iterator]() {
      if (this.left) {
        yield* this.left[Symbol.iterator]();
      }
      yield this.value;
      if (this.right) {
        yield* this.rightSymbol.iterator]();
      }
    }
    ...
    for (const value of myTree) { ... }

Re: ES6 Overview in Bullet Points

#46

Post by ajanuary » Sat, Nov 28, 2015, 9:54 AM UTC

peeters wrote: post #42

ajanuary wrote: post #30

Earlier quoted context omitted.

I've never liked the phrase 'variable hoisting'. It implies the compiler actively moves the variable declaration. What's actually happening is lexical scoping - a variable declaration is associated with a lexical scope. For var declarations, the lexical scope is the function, for let declarations, it's the block. When a variable is referenced, it first looks for the variable associated with the lexical scope of the v…

Thanks for the reply...I definitely get the advantage and popularity of lexical scoping. I'm not sure about your claim about every language doing hoisting though; take Java as an example: class Example { String f = "foo"; void foo() { System.out.println(f); //foo { System.out.println(f); //foo String f = "bar"; System.out.println(f); //bar } System.out.println(f); //foo String f = "baz"; System.out.println(f); //baz…

Java defines the scope of a local variable to be "the rest of the block in which the declaration appears". The variable declaration is 'hoisted' to the top of the scope, which is defined as where the variable declaration is. Tautological! The rest of your example then falls out the fact local variables can shadow member variables [1].

C# scopes local variables more similarly to javascript's "let".

    class Example {
        public void Foo() {
            Console.WriteLine(f); // Error: The name 'f' does not exist in the current context
        }
        
        public void Bar() {
            Console.WriteLine(f); // Error: Cannot use local variable 'f' before it is declared
            String f = "a";
        }
    }

In Bar, it knows about the variable f, evidenced by the fact the error message is different to Foo. In Javascript terminology, f was 'hoisted' to the top of Bar. In regular terminology, f is in the lexical scope created by Bar.

[1] Local variables can only shadow member variables, not other local variables. The justification the specification gives for shadowing is so that superclasses can introduce protected member variables without forcing subclasses to rename their local variables. You can still reference the member variable using "this.memberVariable".

Re: ES6 Overview in Bullet Points

#47

Post by ajanuary » Sat, Nov 28, 2015, 10:03 AM UTC

sixothree wrote: post #13

draw_down wrote: post #6

This is awesome, but can I just say foo/bar/baz drives me nuts. How about `{outerProperty: {innerProperty: 'innerValue'}}` ? That just seems so much easier to follow to me, especially in these deep-nested destructuring examples. But anyway, seriously, this is awesome. The author is responsible for a large part of my ES6 knowledge.

Foo and bar drive me nuts. They feel antiquated and uninspired. If we never see them again it will be too soon.

The advantage of foo/bar/baz is the cultural understanding that the contents isn't important. It's prevalence in programming is because programming languages have strict rules about where tokens are needed. We can't just wave them away, so we fill them with words that we all know mean "nothing important is meant by this".

Things get muddier when you need to say "the contents aren't important, just that it matches this other token over here".

Re: ES6 Overview in Bullet Points

#48

Post by [deleted] » Sat, Nov 28, 2015, 3:10 PM UTC

_greim_ wrote: post #44

Retra wrote: post #22

Earlier quoted context omitted.

It's not hard to read if you already know what it does. As it stands, it's a barrier to learning and a detriment to consistency in style.

> As it stands, it's a barrier to learning and a detriment to consistency in style. Not true. It's actually super-easy to learn and meshes well with existing variable declaration styles.

[deleted]

Re: ES6 Overview in Bullet Points

#49

Post by Retra » Sat, Nov 28, 2015, 3:23 PM UTC

_greim_ wrote: post #44

Retra wrote: post #22

Earlier quoted context omitted.

It's not hard to read if you already know what it does. As it stands, it's a barrier to learning and a detriment to consistency in style.

> As it stands, it's a barrier to learning and a detriment to consistency in style. Not true. It's actually super-easy to learn and meshes well with existing variable declaration styles.

I'm not sure why you spent two lines of text to say "I disagree."

Re: ES6 Overview in Bullet Points

#50

Post by Drawrof » Sat, Nov 28, 2015, 9:44 PM UTC

andreyf wrote: post #32

sotojuan wrote: post #23

Earlier quoted context omitted.

That's definitely another option (and what I use now!), but I do what I posted in Elixir a lot so I guess I'm used to it.

But how is it different from just returning foo?

One difference is that you could return data to callers that you don't want them having access to.