On 08/09/16 23:29, Cedric BAIL wrote: > Hello, > > So I have now landed Efl_Future and Efl_Promise as previously > discussed in a lengthy email thread. The split was necessary to make > it possible to handle the lifecycle using eo object. This > implementation simplify and clarify the API compare to the eina api we > have. > > Still there is some strong concern for me. Efl_Promise/Efl_Future are > primitive that shall not be inherited from as they require manual > binding in every language to take advantage of native asynchronous > behavior as defined in that language. I have given up on Efl_Promise > not being in an .eo file, but not Efl_Future.
First of all, you should make both .eo files, I already mentioned it on IRC. Creating classes manually is discouraged! Second, I still don't quite understand what you mean by this statement. C++ is a language that doesn't have native async behaviour (for all I know), automatic binding for that would work just fine (though maybe a bit odd looking and better to go with the native promise interface). I also have no idea what you mean by no-inherit, what's the problem if someone decides to inherit from a promise and override it a bit? Change some behaviour in the constructor or whatever? Regardless of the above, it should still be in a .eo file, just not shipped (making it essentially private). *NOT* done manually. > > The reason is that Efl_Future being an Eo object make just absolutely > no sense in any context. The only feature we are really using is weak > reference and refcounting when setting multiple callback on the same > future. Other than that we do not rely on Eo at all. It require its > own event propagation and reusing Eo event prototype make the API less > usable actually as we need to do a double cast prone to error in my > opinion. I do also have serious concern on speed and it might affect > us in the future when we start using this more. Remember how genlist > scrolling benchmark is spending more time in eo function than > rendering, not going to improve with this. Could you give examples of the double-cast? The idea is to have a unified API, and not have you reimplement weak-refs and refcounting yet again. Same with callbacks. Benchmark, benchmark, benchmark... > > In any case this is better than our event model based model for > asynchronous request as it ties the result to a specific request. > There is less risk for the user to forget handling the previous > request or setup there event handler to late. Now, what would be > interesting is to see how to integrate that with Gustavo proposal on > channel in separated thread. I don't understand why you keep on saying this. There are other ways to solve async, it just so happens that "promises" are trending nowadays, but there are other solutions. Just to clarify, I'm still against promises (in C). :) -- Tom. ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
