On Tue, 19 Jul 2016 16:35:47 +0100 Tom Hacohen <t...@osg.samsung.com> said:
> 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? i'm mostly fine with it except promise_use - i don't see why really. the then/else cb should handle clearing your stored promise handle. you can use a weak ref if needed too there. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
