Hi,

On 22 September 2016 at 15:34, Davide Andreoli <d...@gurumeditation.it>
wrote:

> 2016-09-22 0:45 GMT+02:00 Gustavo Sverzut Barbieri <barbi...@gmail.com>:
>
> > On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen <t...@osg.samsung.com>
> wrote:
> > > On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
> > >> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen <t...@osg.samsung.com>
> > wrote:
> > >> [...]
> > >>>> promise/future should be first-class citizen... as well as iterator
> > >>>> and the likes. There is a start already, but refinement is really
> > >>>> needed, like returning an iterator<x> should handle warn_unused,
> free,
> > >>>> own... Promise should have its own callback signature, simplified
> for
> > >>>> the user.
> > >>>>
> > >>>
> > >>> They can, be, but they will just be provided by Eo. There's no need
> for
> > >>> any special treatment in Eo.
> > >>>
> > >>> Promise signature: you don't need to do it in Eo. I mean, you can
> add a
> > >>> special type in Eolian, but Eo itself need not be aware. Also, I
> > disagree.
> > >>
> > >> Do you mean still use Eo's events to dispatch promises?
> > >
> > > Not necessarily, just use the same signature because it's a good one,
> > > it's extendable, it applies here too, and it's easier for bindings this
> > way.
> >
> > It's a good one to who? It's a generic one, for sure, but that doesn't
> > make it a good one. Promises, for instance, will carry a value, but
> > it's not immediately available. Even for regular events I don't get
> > why the object must be fetched from the efl_event...
> >
>
> I'm with Gustavo here, reusing the same callback signature for event
> and promises don't seems to be a good idea, it just make the usage more
> confusing and more error prone. Having 2 different signature will make
> the separation line between events and promises more clear.
>

I can hear Cedric screaming in despair on the other side of the planet.

We argued that a single signature was better, as our different callback
signatures (ecore events, evas events. smart callbacks, ...) were one of
the pain points of using EFL. Now it's pretty clear some people want to
reintroduce this with promises vs. events. Gustavo missed these heated
arguments as he started working back on EFL after those long mail threads.
Same for why object is in Efl_Event rather than being in the argument list.

To be fair, promises were supposed to carry a single value only, IOW
Efl_Event.info was supposed to be the value. No double cast. Thinking of
it, I'm not sure why "next" isn't in fact a property on the promise itself
(as it's Efl_Event.object), rather than being awkwardly passed in the event
info -- there may be a good reason. (see also efl_event_callback_stop).

Anyway. I'll wait until I can see *exactly* how async operations (image
file_set in particular) work with promises. Too much arguing about unclear
details until that is done.

-- 
Jean-Philippe André
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to