On 22/06/16 06:34, Carsten Haitzler wrote: > On Mon, 20 Jun 2016 18:07:46 +0100 Tom Hacohen <t...@osg.samsung.com> said: > >> On 19/06/16 02:27, Carsten Haitzler wrote: >>> On Fri, 17 Jun 2016 09:41:39 +0100 Tom Hacohen <t...@osg.samsung.com> said: >>> >>>> On 17/06/16 03:28, Carsten Haitzler wrote: >>>>> On Thu, 16 Jun 2016 19:13:20 +0100 Tom Hacohen <t...@osg.samsung.com> >>>>> said: >>>>> >>>>>> On 03/06/16 20:17, Cedric BAIL wrote: >>>>>> <snip> >>>>>>>>> also promises should become eo objects with event cb's >>>>>>>>> so they work just like everything else. i can ref, unref, delete and >>>>>>>>> whatever them like everything else. >>>>>>> >>>>>>> As said above, this does work. Example with event : >>>>>>> eo_promise = efl_file_set(image, "toto.jpg", NULL); >>>>>>> eo_event_callback_array_add(eo_promise, promise_callbacks1(), NULL); >>>>>>> eo_event_callback_array_add(eo_promise, promise_callbacks2(), NULL); >>>>>>> >>>>>>> In this 3 lines, there is already 2 case in which that fail. First if, >>>>>>> the object is done before the callback is set, data are lost and there >>>>>>> is no way to get any event. Ofcourse, we can override the behavior of >>>>>>> events on this eo_promise completely. Now let's imagine, that we >>>>>>> actually do always store the events, so that everytime someone >>>>>>> register a callback we can send the event. Still you can't auto del >>>>>>> the object at any point in time, you have to force the user to >>>>>>> implement the eo_del and to always provide both a then and cancel >>>>>>> callback. >>>>>>> >>>>>>> Other possibility, it is an event on the object itself. >>>>>>> eo_event_callback_array_add(image, promise_callbacks1(), NULL); >>>>>>> efl_file_set(image, "toto.jpg", NULL); >>>>>>> eo_event_callback_array_add(image, promise_callbacks2(), NULL); >>>>>>> >>>>>>> Same again, this can not work. The first group of event handler, >>>>>>> promise_callbacks1(), may actually be triggered by a previously >>>>>>> running promise on the object, so you have to first forcefully stop >>>>>>> the previous operation. This would add complexity. And still the >>>>>>> second callback has the same issue as the previous case, if it is a >>>>>>> normal eo event, it could have been triggered before any callback get >>>>>>> registered and the event be lost... Same story short, doesn't work. >>>>>>> >>>>>> >>>>>> I'm currently reading through the thread, and I didn't see anything >>>>>> mentioned about this other than a casual remark you made, so just wanted >>>>>> to make it crystal clear regarding implementing it as an Eo object. >>>>>> The whole point/magic of inheritance is that you can and are supposed to >>>>>> override functions if needed. Overriding callback add to call the >>>>>> callback immediately upon addition (if already done) is how I would >>>>>> implement promise callbacks. It's clean, easy and as intended. This is >>>>>> definitely not a problem. >>>>> >>>>> just for convenience i think having a special eo_promise_then(obj, cb1, >>>>> cb2, data); may be best as its the simplest and is not pretending to ADD >>>>> a cb in the name. it sets it explicitly. this needs special treatment >>>>> like the eo event callbacks of course. >>>>> >>>>> but using an eo event is possible by override indeed, but here is the >>>>> issue. you have to wait until either "then" or "else" or both are set. >>>>> since you set one then set another... you will have to always add one of >>>>> them as a NULL or dummy cb just to do this. having a single method/func >>>>> set both makes more sense. in fact this likely needs manual >>>>> binding/.handling per language anyway. i'm really only thinking of eo >>>>> events for EXTRA features like progress events on a promise that happen >>>>> before the success/fail cb's above. >>>>> >>>>> >>>> >>>> This is explained better in my reply to the initial post of this thread, >>>> but essentially you don't. What you are missing, and why life-cycle can >>>> be pretty broken, and why this doesn't matter is that you can register a >>>> few "then" and a few "cancel" in promises. That is actually the power of >>>> promises, that you can chain them and use them for a few things. This is >>>> dealt with nicely. See the post I mentioned. >>> >>> register a few then/else cb's on the same promise? at least that should not >>> be possible (it should not work). on;y one else/then cb (zero or one of >>> each). >>> >>> >> >> Why not? Anyhow, as I said, that is very common in js land and how race >> and all are probably implemented. > > eh? well eina_promise allowed only a single then... which i think is the > sanest > way here. limit it to one. the reason is that otherwise you never know when > the > promise is finished its setup. you need a special done() call on the promise > then to tell it you're done attaching callbacks. e.g. for the case it's an > async load but the load finds the target in an in-memory cache already and > wants to immediately call the then func - when does it call it? if you can add > any number of then funcs... ? >
I already explained this in great length in five different places in this thread. It's very easy to make it work correctly and cover all the above scenarios and more. -- Tom ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
