On Fri, 23 Sep 2016 20:09:01 +0200 Davide Andreoli <[email protected]> said:
> 2016-09-22 8:55 GMT+02:00 Jean-Philippe André <[email protected]>: > > > 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. > > > > 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. they are events. there is a success and failure event. regardless having to remember ANOTHER prototype is mental load and a pain. the whole point of eo was to get rid of our mess of all these cb prototypes and have one single one. a promise fail or succeed is a single event that is called at the end of the lifetime of that promise - like a DEL event on any eo object when its deleted. > 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. i think splitting them is bad. just an object representing the "this thing happens in the future" or the promise object... with a future and promise INTERFACE. one is for the "user" or "consumer" of that promise, the other is for the code that DRIVES the promise - ie tells the consumer when its failed or succeeded. just don't use the interface (methods/api's) that are not appropriate for your side of the promise/future. in js its JUST a promise object for all of this. > > 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- 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
