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. So I agree a promise is an object. But its sole purpose, IMO, is to hold a value that will be available in the future. So both are right. IMO, the only problem with Eolizing Promise is 1. paying for things we don't need; 2. The intricacies of other Eolian features, such as inheritance for example. I'm not completely against it being an Eo object however, though IMO it is not a good tradeoff. But I can live with it and would be really happy to build the JavaScript binding on top of that if I can deliver the same semantics (on steroids) that normal JavaScript promises have. The intrincacies of Eo properties, however, are not very easy to foresee IMO. So, how inheritance should work? This is not a rhetorical question, because right now we have a built-in called promise<T> in Eolian that says that a promise is being returned, because we don't have parameterized classes in Eolian, so how should bindings know that a derived class with more events are being used? If we use the class name of the subclassed promise then we need new syntax to allow parameterizing that in Eolian. Should we? >> 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. > good question. at least in our current usage progress is not used, so... why > not extend that via eo events? this would work in every language we bind to as > long as we return the promise objects from our api's (they will be of the > right > type then with these extensions). OK. > the natural bindings in c++ (libstdc++) have no progress, so when we add this > - > our promises are not 1005 natural. this is something we have to accept, OR we > will require efl to be the lowest common denominator of all languages and that > would be far worse then even just using events on objects for async work. We will accept it can be more than what the language offers. This is common-place even for STL implementations. They have extensions in numerous ways. [snip] >> Regards, >> -- >> Felipe Magno de Almeida Regards, -- Felipe Magno de Almeida ------------------------------------------------------------------------------ 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
