On 20/07/16 00:50, Carsten Haitzler (The Rasterman) wrote: > 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. > >
My whole proposal is based on the lifecycle solution, so if you are saying weakref, it seems like you are against it. A weak ref can't work anyway, because that means people won't be able to copy the variable (which users may) because then the weak ref won't work... Just to reiterate, the suggested API: p = file_set() p.then() //unrefs p and p = eo_ref(file_set()) p.then() p.then() p.then() eo_unref(p) // unrefs p Will be the ways to use it. Just as a side comment: I still don't like the use of promises in the efl. :) -- 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
