On 20/07/16 14:41, Carsten Haitzler (The Rasterman) wrote: > 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). >
You misunderstood me and maybe I misunderstood what you meant before. I believe what you wanted is: efl_file_set(..., &p) // p is now a weak ref ... // p is now automatically null because the object has been deleted. If this is indeed what you meant, then I was right, and it'll lead to broken evilness. For example: efl_file_set(..., &p) pd->file_set = p; ... // p is now automatically null *BUT* pd->file_set is pointing to a deleted object. BAD!!! However, the behaviour you want to achieve is easy to do to an extent, you can just defer the unref to an ecore job/idler. This means that the promise will unref itself after the user has finished using it, and they will be allowed to ref if they so wish. This is essentially the hacky version of what I suggested before, and I wouldn't recommend it. I'd prefer doing what I suggested. Hope things are more clear. >> 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
