0

Assume I have these two functions:

function complex() {
        setTimeout(function() {
                console.log('complex setTimeout');
        }, 1000); // assume this value is random
        function subFun() {
                console.log('complex subFun');
                setTimeout(function() {
                        console.log('complex subFunction setTimeout');
                }, 2000); // assume this value is random
        }
        subFun();
}

function simple() {
        console.log('simple');
}

Assume that I didn't write them - they are third party. Now I want to call them synchronously and get:

complex subFun
complex setTimeout
complex subFunction setTimeout
simple

The problem is, I can't use callbacks (third party functions). I also can't use promises or events (the same reason). I can't use async and step modules, because of functions arity. How the hell can I call simple() after complex() (and all nested sub-functions) synchronously? And do JavaScript sux? :)

dsolimano
  • 8,870
  • 3
  • 48
  • 63
ciembor
  • 7,189
  • 13
  • 59
  • 100
  • Third party or not, you'll have to get rid of every `setTimeout` to do that. – Fabian Lauer Mar 03 '13 at 13:48
  • setTimeout is only to simulate situation when I don't know how long this function (and nested functions) will be executed. This is very common situation. – ciembor Mar 03 '13 at 13:51
  • Ok...I don't see any way except callbacks for chaining functions in JS. – Fabian Lauer Mar 03 '13 at 13:55
  • So the question is - why? Why JS designers doesn't want / can't extend this language with something like a `blocking` keyword? Most blocking languages provides some syntax to create non-blocking functions, why JS can't do that widdershins? – ciembor Mar 03 '13 at 14:04
  • 1
    because if you block JS, you block the entire browser process. JS is not multithreaded, callbacks are weaved into the single thread's execution. And you can ALWAYS use callbacks, because JS lets you take that third part function, tear it apart, and build it back up however you want, then overwrite the original. Sure it's more work, but you can do it just fine. – Mike 'Pomax' Kamermans Mar 03 '13 at 14:27
  • Questions presents questions:). Why JavaScript isn't multithreaded? It's non-blocking by default, so wouldn't it be more flexible (scalability)? I don't talk only about browsers, server-side as well. – ciembor Mar 03 '13 at 14:35
  • also, please change you demonstration code to show what you actually want. replace those timeouts with something real, so it's clearer what kind of codeflow you're up against. – Mike 'Pomax' Kamermans Mar 03 '13 at 14:37
  • The problem is that it's more complex, I tried to abstract and show the problem in general. This bothers me for a while in many different cases. – ciembor Mar 03 '13 at 14:46

1 Answers1

1

How the hell can I call simple() after [the async things] synchronously?

You can't. That's the definition of asynchronous vs synchronous.

If you have that async script without feedback, you have only two choices:

  • poll for the result of the script via a setInterval or similar, and execute simple() after you detected that is has arrived
  • substitute that third party for a better one
Bergi
  • 630,263
  • 148
  • 957
  • 1,375