On Wed, 20 Jul 2016 10:44:09 +0100 Tom Hacohen <t...@osg.samsung.com> said:
> 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... ummm.. they can copy/get the variable in the then/else cb's. after - no. because if you use a weak ref the ref now should be NULL (unless you add an extra eo_ref on the promise before setting then/else). > 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. > -- ------------- 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
