Earlier quoted context omitted.
What would be the point of that? Just return `foo` and destructor in the callee.
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.
[deleted]
ES6 Overview in Bullet Points
31–40 of 50 posts
Re: ES6 Overview in Bullet Points
#32Earlier quoted context omitted.
What would be the point of that? Just return `foo` and destructor in the callee.
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?
Re: ES6 Overview in Bullet Points
#33Earlier quoted context omitted.
checkout Koa to see a great use case of generators. By yielding to asychronous code (instead of callbacks) you can write JS that looks like it's synchronous.
What is the advantage of using generators versus promises?
http://stackoverflow.com/a/28032438 gives a great overview to the pros and cons of both approaches.
Re: ES6 Overview in Bullet Points
#34For those looking for something more in-depth: ES6 in Depth series @ Mozilla Hacks: https://hacks.mozilla.org/category/es6-in-depth/page/2/?utm_... The first article in the above series (where you should probably start): https://hacks.mozilla.org/2015/04/es6-in-depth-an-introducti... Another brief guide to ES6 features, with more code blocks and less bullet points: https://github.com/lukehoban/es6features
Sweet! FWIW there's also an in-depth guide on ponyfoo.com as well.
Starts here: https://ponyfoo.com/articles/a-brief-history-of-es6-tooling.
All articles: https://ponyfoo.com/articles/tagged/es6-in-depth
Re: ES6 Overview in Bullet Points
#35Earlier quoted context omitted.
[deleted]
I guess the point is that: // line 1 { // line 2 let x = 5; // line 3 // line 4 } // line 5 What is the actual end language user difference between saying the scope of x is lines 2-4 but magic (TDZ) makes it unavailable on line 2 vs. saying the scope is from line 3 to 4 with the TDZ being an implementation detail?
One case where the distinction matters is this:
function x() {
console.log(a);
}
let a = 10;
x();
That being said, I agree this is a weirdly overemphasized aspect of ES6. The TDZ is not some weird mysterious boogeyman. It's the thing that makes sense in nearly all cases.
Re: ES6 Overview in Bullet Points
#36If you're interested in using ES6 features, TypeScript provides a great way to get most of these features (and of course optional typing as well). Babel might be slightly more feature-complete when it comes to ES6 features, but TypeScript provides such a fantastic front-end dev experience that I definitely recommend it. (Biggest pain point is incorporating typings for libraries which are pure JS and not TS.)
Re: ES6 Overview in Bullet Points
#37[deleted]
Re: ES6 Overview in Bullet Points
#38Great 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?
It's the new with.
Re: ES6 Overview in Bullet Points
#39Does anyone have any idea why WeakMap and WeakSet aren't iterable?
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 essentially forces a GC pass because it needs to know whats reachable and what isn't at iteration time.
Re: ES6 Overview in Bullet Points
#40Does anyone have any idea why WeakMap and WeakSet aren't iterable?
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 isn't at iteration time
Why would it need to check what is reachable or not before iteration? WeakSet doesn't guarantee that it only contains otherwise live objects does it? The Mozilla documentation just says that the references in a WeakMap or WeakSet 'do not prevent garbage collection'. It doesn't say a WeakMap 'only contains otherwise live objects'. It makes no guarantees like that at all.
However I'll answer my own question as I found some more documentation - it's apparently to reduce non-determinism, so that you can't observe the operation of the GC.