On Wed, 20 Jul 2016 14:47:19 +0100 Tom Hacohen <t...@osg.samsung.com> said:
> 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. no. i actually mean eo_weak_ref()/eo_wref_*(). using that. mydata->p = whatever_async_do(); // returns a promise eo_weak_ref(&(mydata->p)); eo_promise_then(mydata->p, then_cb, else_cb); // here on then/else may becalled // here promise could be invalid BUT the wo weak ref will ensure that mydata->p // is either a valid promise OR it is NULL. i MUST remember to: // eo_weak_unref(&(mydata->p)); if i free mydata or i want to overwrite // mydata->p with something else. > 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. no - i just use ACTUAL weak refs. :) if i want to guarantee it stays around until I AM EXPLICITLY DONE then i would do: mydata->p = whatever_async_do(); // returns a promise eo_ref(mydata->p); eo_promise_then(mydata->p, then_cb, else_cb); and then only eo_unref(mydata->p); when I want to - so not in then/else_cb but maybe inn a job as you say or a timer or on exit of process. whatever. :) > 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. > >> > > > > > -- ------------- 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
