On Thu, 22 Sep 2016 15:55:33 +0900 Jean-Philippe André <[email protected]> said:
> 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. tbh efl_future should have a value_get to get it from the future. it should ALSO have a progress_get that gets some double. this should be there either way and store the last known progress or the value once success/failure is hit. this makes it perfectly simple and clean. same with getting the next future - get it from the future object. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
