

JQuery 1.5 promises a better future. - illumen
http://renesd.blogspot.com/2011/01/jquery-15-promises-better-future.html

======
drags
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>

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

------
ot
> jQuery is using promises, and not futures.

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

~~~
weavejester
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.

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

~~~
weavejester
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.

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

~~~
weavejester
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.

