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.
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
