JQuery 1.5 promises a better future. | Hacker News Reader

JQuery 1.5 promises a better future.

renesd.blogspot.com

118 pointsillumen8 comments

Here's a great explanation of a) what promises are and b) how the promises/deferreds code in the $.ajax method is being refactored out for general use: http://blog.rebeccamurphey.com/deferreds-coming-to-jquery

Thanks, I was just coming to ask for something like this.

> jQuery is using promises, and not futures.

Can anyone explain the difference between promises and futures? I've always used the terms interchangeably.

My understanding is that a future's value is supplied by the function it is created with (which is evaluated in a background thread), whilst a promise's value is delivered by another thread. Both constructs will block if accessed before their value is resolved.

This seems to me an implementation detail, are there any observable differences?

Futures always start a new thread, whilst a promise can receive its data from an existing thread.

In practise, this means that futures are best used for multi-threaded calculations, whilst promises are best used for handling events from I/O or some other unpredictable source.

For example, we can assign a promise to get a key-press:

    var keyCode = promise();

    document.onKeyPress(function(event) {
        keyCode.deliver(event.keyCode);
    }

But if we tried to use a future, we'd have to do something like:

    var keyCode = future(function() {
        while (true) {
            var event = waitForEvent();
            if (event.type == "keypress") return event.keyCode;
        }
    }

The future is essentially wasting a thread waiting for input, whilst the promise is inert until a keypress occurs.

Mmh, I've never seen a "future" like that, it seems to me more of a "worker"...

That's pretty much how all futures are implemented. Some implementations have an executor object that determines the size of the thread pool and so forth, but the basic principle is the same.

For example, in Python it's:

    executor = ThreadPoolExecutor(max_workers=1)
    x = executor.submit(func, arg1, arg2)
    print x.result()

In Clojure it's:

    (let [x (future (func arg1 arg2))]
      (println @x))

In Java:

    ExecutorService executor = Executors.newFixedThreadPool(1);
    FutureTask<String> x =
        new FutureTask<String>(new Callable<String>() {
            public String call() {
                return SomeClass.func(arg1 arg2);
           }});
    executor.execute(x);
    System.out.println(x.get());

Basically the same idea; execute some code in a background thread and return the result when asked. If the result isn't ready, then block.

Apparently some languages use a callback to get the result, rather than blocking, but the most common approach I've seen is just to block the thread until the future is finished.

Reply on news.ycombinator.com