On 27/06/16 17:56, Cedric BAIL wrote: > 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 ! >
We are on a streak, we also agreed on something else the other day. I flagged this to follow it up, but unfortunately this got no other replies. What's the status? Is this going forward? Do people like it? I went through the rest of the thread, there was nothing there that seemed to negate this, or a better alternative. What's the status of promises following this thread? -- Tom. ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
