On Mon, Sep 12, 2016 at 10:14:27PM -0300, Gustavo Sverzut Barbieri wrote: > On Mon, Sep 12, 2016 at 10:00 PM, Simon Lees <[email protected]> wrote: > > On 09/13/2016 09:39 AM, Cedric BAIL wrote: > >> On Mon, Sep 12, 2016 at 2:11 AM, Tom Hacohen <[email protected]> wrote: > >>> On 08/09/16 23:29, Cedric BAIL wrote: > >>>> So I have now landed Efl_Future and Efl_Promise as previously > >>>> discussed in a lengthy email thread. The split was necessary to make > >>>> it possible to handle the lifecycle using eo object. This > >>>> implementation simplify and clarify the API compare to the eina api we > >>>> have. > >>>> > >>>> Still there is some strong concern for me. Efl_Promise/Efl_Future are > >>>> primitive that shall not be inherited from as they require manual > >>>> binding in every language to take advantage of native asynchronous > >>>> behavior as defined in that language. I have given up on Efl_Promise > >>>> not being in an .eo file, but not Efl_Future. > >>> > >>> First of all, you should make both .eo files, I already mentioned it on > >>> IRC. Creating classes manually is discouraged! > >> > >> Yup and to repeat my point here, I want to make that nobody mess with > >> efl_future in any way that could break bindings. There is basically > >> absolutely no way to modify an efl_future behavior without resulting > >> in binding not able to pick the new behavior. efl_future are what > >> define asynchronous behavior, altering them is a sure receipt for > >> borkage and I see no win for a simple, well defined and limited class > >> to be in a .eo file. > >> > >>> Second, I still don't quite understand what you mean by this statement. > >>> C++ is a language that doesn't have native async behaviour (for all I > >>> know), automatic binding for that would work just fine (though maybe a > >>> bit odd looking and better to go with the native promise interface). I > >>> also have no idea what you mean by no-inherit, what's the problem if > >>> someone decides to inherit from a promise and override it a bit? Change > >>> some behaviour in the constructor or whatever? > >> > >> Inheriting from efl_promise is a maybe safe behavior. I say maybe > >> here, which is why it is in an .eo file. Still I will strongly > >> discourage to do so as some language may not be able to pick up the > >> altered behavior. It is still less of a problem than efl_future. As > >> for automatic bindings, it obviously can not work, especially for C++, > >> as there is no possible type information defined in .eo and you need > >> to implement efl_promise as a template. > >> > >> The second reason, to the opposite of what you believe, C++ and its > >> standard library do come together and promise/future is part of it and > >> defined the way to have asynchronous behavior in C++ with threads. Our > >> take on it is compatible and extend it to be integrated with efl main > >> loop. So you do have a notion of native async behavior. > >> > > > > In Qt async behavior using its event loop was also really common, we > > used to use its timers + signals / slots to do this often, > > QTimer::singleShot(500, this, SLOT(myFunc())); for example was used all > > the time to trigger something async in 500 ms. > > I guess this is because it predates the c++ standards... Qt does a lot > on its own due that. > > OTOH, your Qt example reminds me how awful the new code is in C, to > create a single Ecore_Job, previously ecore_job_add(cb, data), now > it's 2 lines + error check... if you want to play well with future > multi-mainloop it's even worse: > > Eo *loop = efl_loop_user_loop_get(o); > EINA_SAFETY_CHECK_ON_NULL_RETURN(loop); // loop may be null if > obj was unparented, like efl_del() > promise = efl_loop_job(loop, o); > EINA_SAFETY_CHECK_ON_NULL_RETURN(promise); > eina_promise_then(promise, cb, cancel_cb, data); > > Or timer = ecore_timer_add(seconds, cb, data), now: > > Eo *loop = efl_loop_user_loop_get(o); > EINA_SAFETY_CHECK_ON_NULL_RETURN(loop); // loop may be null if > obj was unparented, like efl_del() > timer = efl_add(EFL_LOOP_TIMER_CLASS, loop, > efl_loop_timer_interval_set(efl_added, seconds), > efl_event_callback_add(efl_added, > EFL_LOOP_TIMER_EVENT_TICK, cb, data)); > > come on... there must be a way to simplify these things :-( > > to that extent Qt pre-processes all files and translates slots and > signal connections to plain C++, keeping it fast yet easy to use.
There could be a helper method which does the "fetch the loop and create the job" stuff. But with the feature of multiple efl loops in one process you have to decide on which loop to run the timer, i dont really see how you can get arround deciding that ... Greetings bu5hm4n > > -- > Gustavo Sverzut Barbieri > -------------------------------------- > Mobile: +55 (16) 99354-9890 > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
