On Thu, 29 Sep 2016 17:38:17 +0200 Davide Andreoli <[email protected]> said:
> 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 actually agree with this. instant resolution causes problems. deferring it until later even if the result is available now, but using something like a job to do it is going to be much easier to work with from the api users point of view. then the promise calls always get called later where you'd expect them to be (and if the resolution Is instantly possible it's just later within the same loop run). also if we were to do instant resolution we would break this above js rule in our js bindings because we would drive the promise callbacks where they should not be. no matter the async solution we have i think this is a good rule to follow. > 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? as above. the es5 rule is right. always defer even if result is known now. > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
