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. 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. 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. HAve fun, -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
