On Tue, Apr 23, 2013 at 6:12 AM, David Bruant <bruant.d@gmail.com> wrote: > Anyway, my point was that there exist libraries in which "then" is a > function and the object with this function isn't a promise. These libraries > will end up in a terrible confusion when used with Futures. > You think you're resolving a future with an object and... oops! the built-in > Future algorithm confused your object for a promise. Suddenly, not only are > you not resolving your promise with the value, but your .then method is > called unexpectedly. Agreed. I'll note, though, that if the semantics of .resolve() are non-recursive (it strips off one layer of promise/future, but no further), then this becomes somewhat less of an issue, as it can be worked around - if you want to return something that's not a promise, just wrap it in a fulfilled promise (via some sugar function - I've proposed such in www-dom). That wrapper will be unwrapped straight away, and the future accepted with the value within. The big problem only arrives if you both treat all thenables as promises/futures, *and* have recursive resolve semantics, because then you can't *ever* return a non-promise with a .then() method. I'd prefer that resolve only strip away a branded future, not an arbitrary thenable, and for there to be a way to brand a thenable as a future. That way, using other-library promises just requires one trip through the branding function and they can interoperate. Existing libraries tend to expose the same mechanism already, so that the other-library promises expose all the proper methods of the "main" library. But I want non-recursive resolve *more*, and if I was forced to choose one, would take monadic resolve over branded futures. ~TJReceived on Tuesday, 23 April 2013 18:03:45 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:12 UTC