Hi, On Thu, Sep 29, 2016 at 8:38 AM, Davide Andreoli <[email protected]> wrote: > I'm starting this new thread to further discuss promises, thus the tag > [YetAnotherPromiseThread] :)
:-) > It seems to me we are putting too much ideas/discussion in the other > threads in a so sparse way that is starting to be difficult to follow the > discussions and to understand when we found some agreement, so please try > to don't go off-topic in this one. > > The topic here is: do we really want to allow instant resolution of > promises? > For "instant resolution" I mean a promise that will call the user callbacks > as soon as the callbacks are "connected", thus in the middle of the user > code. (we took as an example a cached promise value) What we want is to be able to set failure or success before even a future is given to the user, but that doesn't mean we need to fulfill it right away. > I read lots of JS promise docs in these days and one that I like is: > https://promisesaplus.com/ > > Especially I'm pointing to: > 2.2.4 onFulfilled or onRejected must not be called until the execution > context <https://es5.github.io/#x10.3> stack contains only platform code > > This point (as explained better on the site) means that "instant > resolution" is forbidden in JS. > > I know we discussed this already, but it's a point that still scare me and > I fully understand why it is forbidden in JS. From a user perspective pov > having to think at both possible code flow that we are allowing (promise > callback called NOW, in the middle of the code where you define them, or > callback called later) can be really difficult to get right and error prone. I like this point and it makes a lot of sense. So yes, I am for delaying the resolution. > Also if we go to an "always async resolution" approach we can probably > remove lots of complexity in the promise implementation and in the promise > API. Not really, it will be slightly more complex as we really need to keep the behavior of being able to set success/failure right away (useful for transitionning and cache implementation). > So what do you think? really we need this double-possible-behaviour in our > promise implementation? I think it is a good idea, pretty straight forward to implement. It will mean we do not need to ref/unref for reusing the same future for multiple callback. The main issue is that you absolutely need a main loop to implement this behavior (Not a problem from my point of view). It will be easy to implement and will simplify API use. -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
