On Sat, 25 Jun 2016 11:38:46 -0300 Felipe Magno de Almeida <felipe.m.alme...@gmail.com> said:
> 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. the was we have promises, they go beyond just holding a value for the future.they hold a series of callbacks to call on success or failure AND they also hold progress events AND they have cancel methods on them. they can be reference counted too. to my mind, that makes them pretty much full featured objects in the efl/c sense. yes in c++ everything is an object. :) but in the c world wse have a dividing line from objects to data structures and then another to basic types. basic types (int, double, char, int[], void * etc.) are clearly defined by the language. data structures are what we define in eina. objects are everything else above. at least to me, promises are being used to replace existing objects we have (timeouts, jobs) and so should be eo objects. :) yes - i know there is a cost. giving it some thought, that cost is, in the big picture, not that high (think about how often promises will be created/destroyed and methods called on them and then figure out the delta between eo and the eina_proimise... and then consider how often we call other things... and the real work behind it all) > 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. i definitely think you can do that. i have a different view on the cost, and we can reduce the cost at least of creation and destruction to something equivalent to eina_promise > 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? our promise<t> should be ours imho with whatever extensions (like cancel) that we have. if we allow inheritance then well.. we need new types like promise.progress<t> or something. or should we dump progress in the base promise class? > >> 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. why not just call progress events whenever they happen. if no event is registered at that time - nothing is called. at least from a set-up point of view, you should set up the progress event BEFORE setting up then/else. you may or may not get any progress events before then/else. as long as this is a defined semantic... i can't see how we'll get a deadlock? > > 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. then we agree that our promises will be extensions in most languages from the core native promises, and so we agree that requires us to return promises to ensure they are of the correct extended type. right? > [snip] > > >> Regards, > >> -- > >> Felipe Magno de Almeida > > Regards, > -- > Felipe Magno de Almeida > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
