On 25 June 2016 at 16:38, Felipe Magno de Almeida <felipe.m.alme...@gmail.com> wrote: > On Sat, Jun 25, 2016 at 11:12 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: >> On Sat, 25 Jun 2016 10:28:37 -0300 Felipe Magno de Almeida >> <felipe.m.alme...@gmail.com> said: >> >>> Hello, >>> >>> I still don't get it why promises should be an all-or-nothing thing. It must >>> be usable for all scenarios possible or we should drop it and >>> live with events which are impossible to translate to the real semantics >>> of asynchronous operations (I'm calling an asynchronous operation >>> one that returns a value asynchronously) to bindings that already have >>> a concept of asynchronous operations. >> >> i don't know if anyone said it should be all or nothing. i have said that >> given >> the newness and disagreements on promises that we need to use them very >> carefully and avoid usage "all over the place" for now until we can settle >> them >> down. if we were all happy with them and agreed on them then things may be >> different, but that is not the case. >> >> i think a big difference is our view of promises. to me a promise is an >> OBJECT >> that REPRESENTS the async action (and then is responsible for calling the >> correct callbacks and for storing the value until all such callbacks are >> called >> etc. etc.). you (and cedric) keep referring to promises as async values. at >> least in every language binding they are OBJECTS. they have methods on them >> (p.then(), and to cancel p.cancel() for starters). > > Well, the object nomenclature is a little misleading IMO. For C++ at least > everything is an object, even ints. ...
no, not ints :) >>> One example is making promises open to add new events through >>> inheritance. However, let's say that it is really desirable, so we can >>> all compromise on a middle term, we need to have a way to support >>> that in bindings in a way that is natural in the binding languages, and >>> IMO that is the _most_important_part_ and I have been repeating >>> myself about this since I introduced the promise idea in january, but >>> let me repeat again: >> >> yes, and since promises are objects in every language and binding we >> support... >> this isn't much of an issue. we can extend progress events as eo events since >> they wont be a minimal base requirement. will these events be really common? > > I actually like the idea of using events for progress, because it is an event, > it has all the properties of events. However, it just has one single problem, > which is the race condition of progress being available and when the event > is registered. This problem also existed with Eina_Promise however, and > we fixed by adding strict_promise concept which would only send progress > when a progress callback was registered. This could be case for Eo as well, > but we need to be able to differentiate, because a strict_promise can lead > to deadlock if the user never registers any progress callback. What's the strict progress good for? Just cache one progress event until a progress callback is registered or the promise is deleted. If new progress event is sent it is cached and the old one deleted. That way when the progress callback is registered it has latest progress information. Thanks Michal ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
