On Thu, Sep 15, 2016 at 3:41 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Tue, 13 Sep 2016 19:53:20 +0200 Davide Andreoli <d...@gurumeditation.it>
> said:
>
>> I disagree here, really you are saying that only raster use async stuff in
>> efl?
>>
>> >From my POV efl is (and has always been) a fully async toolkit, and I use
>> lots of async stuff in all my programs: timers, animators, idlers,
>> ecore_con,
>> ecore_exe, ecore_fd, edje_signals, emotion callbacks, etc...
>>
>> And to be honest I never feel the need for a better async API...
>
> well long before promises here was my thought:
>
> we have async in our api by callbacks. we haven't made things as async as they
> should be - like file_set or evas images, edje objects etc. with some
> returning
> true/false for initial success. this was a mistake. for eo we should basically
> indicate success later async (if you care), or have a stop-and-wait api if you
> must know now. (obj.wait() ?).
>
> the real issue is many objects would DO something async and the event name was
> different from object to object. ecore-con was different to ecore-ipc (though
> very similar). elm image different to evas image, different to edje objects
> etc. so you couldnt apply a pattern and just dumbly copy and paste to have
> your
> cb called "when its done".
>
> so my thoughts were for eo to at least have some core async interfaces that
> all
> these objects share to do the wait, provide a set of core standard events etc.
> - this would reduce the mental load for developers using such api's as they
> can
> re-apply the same knowledge directly across multiple objects.
>
> what i liked is the simplicity - just create the obj (image, edje, server,
> etc.) add event cb's you care about, then "do" the action (set file, connect
> etc.)
>
> promises do bring in standardization like above, BUT they do it with a lot
> more
> complexity by having another promise object that is created for that action on
> which you then have to listen for the completion or failure etc.
>
> i understand why technically it has to be this way, BUT it's incredibly
> painful
> to deal with. i know i'm not the only one using async api's in efl - and they
> are not that hard to deal with, but as above, could do with improvement.
>
> i'm dubious about promises still. i see value but i also see downsides. i
> think
> they are such a radical change from what has been proven to work that the WISE
> thing to do would be to use them in a limited number of places for now and
> "see
> how that pans out".
it's easier to chain individual stuff as it would require you to
event_callback_{add,del} to do that with simple events. Not to say
that it's easier to understand flow from:
promise = action()
promise = promise.then(another_action);
promise = promise.then(yet_another_action);
Than to look at event_callback for action (needs mental 1 translation,
as you said), then read another_action's code and see it will do
something that generates an event, then do another mental translation
to find yet_another_action, then remember all of that to create a
picture of the flow with was concisely described above in 3 lines :-)
> so my take is what tasn said - let's TRY promises in SOME areas and see, but
> let's not go all-in on them. what "some areas" are is a bit fuzzy though...
> it'd be good to discuss where we should use promises for now and perhaps have
> an alternative way of doing the same thing and see which one people gravitate
> to... then again having 2 ways to do the same thing is confusing especially to
> newbies... :( ARGH!
my hope is that we can allow promise-only programming by allowing some
events to auto-generate them, something like:
EFL_PROMISE_FOR_EVENT_GENERATOR(button, EVENT_CLICKED,
{.cb = action, .failure_cb = bla},
{.cb = another_action},
{.cb = yet_another_action, .failure_cb = blergh});
see my email to cedric on some C-only macros that we should offer to
ease our usage in C, they could be created in a more C++ fashion in
their bindings and Python/JS/Lua don't need such things.
Likewise, you could generate a promise for an event (one-shot), like
"another_action" above could wait for "EVENT_CHANGED":
Promise *another_action(void *data, const Eina_Value *value) { //
see my reply to cedric!
Ctx *ctx = data;
return efl_promise_for_event(ctx->entry, EVENT_CHANGED); // one shot
}
Promise *yet_another_action(void *data, const Eina_Value *value) {
Ctx *ctx = data;
if (eina_value_type_get(value) == EINA_VALUE_TYPE_STRINGSHARE)
{
const char *str;
eina_value_get(value, &str); // maybe add helper const
char *eina_value_string_get(value)
efl_text_set(ctx->label, str);
}
return promise_finished();
}
The idea is that you create an event listener that creates the
promises using the flow defined in the parameters, making the
programming easier.
--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (16) 99354-9890
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
