On Sat, Jun 25, 2016 at 7: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: > 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).
This pretty much explain all disagreement and missunderstanding here. I haven't realized until you said so that you expected to use "promise" in that way. This match closely what you have done with "vpath" in fact and not at all what is understood to be a promise (a.k.a. a container for a future value) in most language. I am not a fan at all of inventing our own concept that doesn't match the rest of the world, but my strongest reserve is that I think this lead to more problem than it solves. First the problem that this does solve. As there is no owner of the write side of the promise, only internal use, you do not have this lifecycle problem at all and as you also advocate for only one listener, it means you also avoid the problem of having to keep the n user of it happy. This solve the lifecycle issue I have been discribing since the start with using eo for this purpose. The most important problem I see. If the operation is to be done from the inside of the promise, using it in object like efl.canvas.image, means that either you get efl.canvas.image to have a priviledge access to the internal of the promise, so that you can force its resolve on demand, or you need to implement a wait on most promise with the risk of ending in deadlock. That and the fact it doesn't match what other language are providing, are in my opinion the biggest problem I see with this idea. Also in most case where we use promise at the moment they are literrally under the control of another object as they are just delivering a result for an existing object. The only case where we could use this behavior at some advantage is for Eio promise, but even then I am not to sure of the outcome. We could in that case extend signals for filtering and sorting on the promise (progress should be part of the default property of a promise as this follow ES6), but this become something bindings have to care about. This is going to be tricky when we are chaining promise. What happen to this events once put into an all/race/chain promise ? Whatever extention we use on a promise, it will be tricky to have them available outside of C. On the other hand sticking with a more classic promise/future container concept, we can avoid the problematic exposition of wait and the risk of a deadlock as any object that would require to resolve a promise could force it internally. It also means that instead of having a one promise that does everything like vpath, you go by chaining them. A first one that resolve an uri to an Eina.File and in the then of that promise you set the file on the destination object. This means that the destination object doesn't need to resolve a file download before it is done and you have no dead lock. Now I can see that extending the promise/write side could be useful in some case and not risky as it is hidden from bindings completely as they only needs to actually expose a future. So when you actually extend a promise/write side it stay actually hidden from the binding and doesn't create any trouble there. Thinking more about it the main issue we were facing with using Eo and its lifecycle is that we wanted to save on performance by merging the promise and future together. This lead to having an ownership problem, with parenting and reference counting issue. If everytime you call future_get you get a new Eo object connected to the promise, but not the actual promise itself, this solve all problem too. This solve the refcounting and parenting issue as the one who get the future is actually the one who own the future. This will increase the pressure on eo_add, but whatever. The promise/writer side will be an eolian object and can be inherited from. The future/reader side is I think to tricky and risky at this stage to allow it to be inherited from. As we clearly split both side, I think the future/reader side should be an Eo object only. In the future, if we are confident enough and find use case for exposing it as an eolian object and make it inheritable, we will still be able to do it, but for the time being, it is much more safe to not provide that feature. -- Cedric BAIL ------------------------------------------------------------------------------ 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
