kzbin.info/www/bejne/epazdmOcm86AnJY

For some reason Crockford hates the arrow function. He thinks it's a tool of the hipsters and prefers using the word function. Old guy - can't keep up with the trends ;)

@@anthonytonev1357 he says it's bad to overload symbols that have other meanings and I agree. Function isn't that hard to type.

whether or not the functions are written with fat arrows is irrelevant. the important part is to understand the diferent functions presented in the workshop, so you can apply them in your own code ;)

Seriously, yeah. This was supposed to be an advanced JS presentation, for experienced programmers of other languages and/or people that know JS already. One guy there didn't know what was heap and stack, and (maybe the same) didn't even seem to know what was an element id.

Un BelExité :-D thought the same...

Yes, it's indeed the same and it's not too difficult to see such. The case he presented is basically var f = (function(){}()), which is the function being created and invoked inside of the paranthesis. Yours is basically var f = (function(){})(), which is the function being created inside the paranthesis and invoked outside of the paranthesis. In the end, there's really no difference. You could even leave out the paranthesis entirely and simply write var f = function(){}()

You shouldn't use this type of structure anymore. We have let and const now, which have block scope and don't require IIFEs like this.

@@MarcosSandrini I think those "private" variables, aswell as closures does not work with the garbage collector in JS.

to me too :)

crockford.com/pp/problems.pptx i.imgur.com/0eucXcM.png - [Student] Type check the subscriber before you push? - No, the subscribers have to be functions. In fact, that's what the try-catch was for, to guarantee that there are functions. - [Student] Okay. - [Student] Can you... nevermind. - [Student] Could you just temporarily change the value of publish to something else, but it's frozen? - Right, we have. We fixed that one. - [Student] I was just trying to think of a way to disable publish inside this loop. So if you just set ... Yeah, you put a var at the top that says publish off. - Yeah, we could put a Boolean up at the top which says, "We're in the publication mode so publish is turned off while we're looping." That would certainly work. The way I would approach it is, I would do an asynchronous solution, because I like asynchrony. So, there's something that's in browsers and in Node called setTimeout. And setTimeout receives a function and causes that function to get executed in the future. And you can give it a time which says no sooner than zero milliseconds from now, call this function. But this function happens in a different turn, so it will get scheduled after all the current work and the current term is finished. So this would cause everything to get lined up in the timer queue, and then if someone wants to subscribe during the publication, their stuff will get added later in the timer queue. So, everything stays in order. We're using a timer queue to sort the messages. - [Student] So you move the publication off into a separate queue that will all gets processed independently of whatever goes on here. - Right It also means that I don't need to try-catch here now, because, if it fails, it will in that turn, but then the system says, "Well, that turn's finished," and it will go on to the next one. So, everything keeps going. Now, it turns out there's one hazard to this because of a design error in the way setTimeout works. When you call setTimeout, it returns a number, and you can pass that number to clearTimeout, and that'll prevent things from happening. Unfortunately, it is an easily guessable number, and that means that, if the attacker can guess what the next clearTimeout number is going to be, he can prevent messages from being delivered by canceling those messages that are in the queue. So, we would have to fix that, but we'll fix that one another day.

@@antonlee0 how would setTimeout solve the problem?

No.