On 22/09/16 07:55, Jean-Philippe André wrote: > Hi, > > On 22 September 2016 at 15:34, Davide Andreoli <[email protected]> > wrote: > >> 2016-09-22 0:45 GMT+02:00 Gustavo Sverzut Barbieri <[email protected]>: >> >>> On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen <[email protected]> >> wrote: >>>> On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote: >>>>> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen <[email protected]> >>> 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. >
Every word in stone. I'm kind of tired at this point by rearguing everything all the time. It has already been discussed to (my) death. -- Tom. ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
