2016-09-22 8:55 GMT+02:00 Jean-Philippe André <j...@videolan.org>: > 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. >
For what I remember we discussed that all EVENTS must use the same signature, and I'm ok with that. But promises are different, they are not events. But I agree with you that we are arguing too much without a clear view of what we have now and what we are going to implement wrt promises and future. At this point I'm also confused between future and promise... I highly suggest to write a wiki page with all the needed explanations and examples usage for both promise and future , so that we can discuss with a documented base. > > 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 > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
