On Mon, Jun 27, 2016 at 4:50 AM, Tom Hacohen <t...@osg.samsung.com> wrote: > On 19/06/16 02:52, Carsten Haitzler wrote: >> On Fri, 17 Jun 2016 09:57:47 +0100 Tom Hacohen <t...@osg.samsung.com> said: >>> On 17/06/16 03:53, Carsten Haitzler wrote: >>>> On Thu, 16 Jun 2016 20:11:09 +0100 Tom Hacohen <t...@osg.samsung.com> said:
<snip> >>>> as i said... i don't think we need a promise on these objects. we already >>>> have an object to store the value/state of the load. it can already call >>>> event cb's when these actions succeed or fail. we have done this with >>>> preload for years already. if you do another file_set it does cancel the >>>> previous one by definition (the only q is if that means you have to call a >>>> load fail callback of some sort). >>>> >>>> this is what i mean by "let's not use promises here because at this stage >>>> they do not help, just cause more work, complexity etc.". >>> >>> I 100% agree on this, we don't need to use promise for file_set! Using >>> file set was just an example though for the life-cycle issue. The >>> life-cycle is the problem I was addressing here, and I don't think it's >>> solved in any way but my last example. >> >> i dislike making people have to del their promises when they can be taken >> care >> of by themselves. look at timeouts and jobs. they are promises now and if you >> have to create a job that returns a promise... then have to del it >> but it will later be called... that just looks WRONG. reading such code makes >> it look broken. it'll be confusing to people to no end. having a single ref >> and >> that ref is unreffed after then/else is called will be just fine. only allow >> a >> single then and/or else cb to be set up. :) > > I suggested we do the same we do for proxies. > p = file_set() > p.then() // unrefs p > > While: > p = eo_ref(file_set()) > p.then() > p.then() > p.then() > eo_unref(p) is allowed and encouraged. Which is basically my proposition added the promise_use for when you want to be able to call cancel on it and enable also the possibility to actually make promise optional. Also this way we can merge sync (In the sense that any further request on the same object that require the result of that said promise) and async API instead of doubling our number of symbol as you did suggest in a previous post. Should I count that as me agreeing on Tom proposal ? Sounds weird ! -- Cedric BAIL ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
