On Thu, 29 Sep 2016 09:50:19 -0700 Cedric BAIL <cedric.b...@free.fr> said:
> Hi, > > On Thu, Sep 29, 2016 at 8:38 AM, Davide Andreoli <d...@gurumeditation.it> > 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). yes. you need to be able to SEt success/failure immediately, but you need to defer the CALL that propagates the result to the user of the api. that does require some code/work. > > 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. i'm ok with needing a mainloop. we're centered on that design anyway. in fact assuming a loop in eo opens up so many doors like eo being able to manage caches within a loop cycle (eg keep some trash around in case it needs re-use or just to defer deletion/destruction, and then nuke it when the loop goes idle and is going to sleep - at least it defers that overhead until after a frame has been rendered thus hopefully reducing latency a bit ... for example). i can see how we do have to kind of blur the lines between eo and the loop. as i said before - trying to avoid this is like what i tried to do with evas (make it loop agnostic and avoid knowing about such things so it could be used in multiple toolkits - that never happened and evas has been hurt by that design decision). i think the same applies to eo here. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
