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) 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. 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. So what do you think? really we need this double-possible-behaviour in our promise implementation? ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
