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. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
