modisposition

Programming with queues is basically what we do in any case: it does not matter if we write code in that way, we simply think in that way. This means that our logic flow is generally distributed in tasks where "on case X" we apply "logic/procedure Y" .. isn't it? The Good'ol GOTO The goto statement has been historically criticized, as well as the switch one, and in both cases is about entry and exit points in a generic workflow. Nowadays, we can say the GOTO is not needed anymore thanks to functions, where rather than thinking " when this case occurs, goto this instruction " we call the required function in charge of that specific task providing arguments or context as we go. We may then agree that GOTO is not really a must have while functions are, with all the power and flexibility we might need, and specially in JavaScript. On Block-Scope JavaScript has theoretically no block-scope concept, at least until very latest versions of ECMAScript whe...

The Code This is the 138 bytes version: function Queue(args, f) { setTimeout(args.next = function next() { return (f = args.shift()) ? !!f(args) || !0 : !1; }, 0); return args; } While this is the 96 one: function Queue(a,b){setTimeout(a.next=function(){return(b=a.shift())?!!b(a)||!0:!1},0);return a} The Why In almost every QCon London talk I have heard the word asynchronous . Well, the aim of the tweet sized function I have just written above is to make things easier. After I have implemented builder/JSBuilder.js for wru , so that Python is not needed anymore to build the tiny library, I needed to make builder/build.js usable in a way that asynchronous calls through node won't bother, at least visually, the normal flow of the script. After that I have thought: " why not making a generic Queue function with Promises like approach " ? The What It's quite straight forward, you create a queue, you use the queue. You might eventually pollute the queue or chang...