On 6 November 2012 20:55, David Herman <[email protected]> wrote: > - a way to create promises that don't expose their internal "resolve me" > methods, etc. so they can be delivered to untrusted clients, e.g.: > > var [internalView, externalView] = Promise.makePair(); > "resolve" in internalView // true > "resolve" in externalView // false
Indeed. I think this is an issue where many promise/future libraries are confused/broken. FWIW, when creating a concurrent language called Alice ML some 15 years ago we thought about this quite extensively, and ended up introducing the following separation of concepts: * Futures are handles for (potentially) unresolved/asynchronous values, on which you can wait and block -- but you cannot directly resolve them. * Promises are explicit resolvers for a future. More specifically, creating a promise creates an associated future, which you can safely pass to other parties. Only the promise itself provides the fulfill method (and related functionality) that enables resolving that future. In other words, futures provide synchronisation, while promises provide resolution. Incidentally, that's also exactly the model and naming that C++11 picked. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
