On Sun, Jun 19, 2016 at 9:32 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 18 Jun 2016 23:06:35 -0300 Felipe Magno de Almeida > <felipe.m.alme...@gmail.com> said:
[snip] >> I have explained in the email exactly how they would be translated to C++, >> JS and Lua by _not_ being a object used directly by the user translated >> automatically by Eolian. So I don't know what you mean. JS will be used > > that is the ONLY way for them to work right. to be translated. have you looked > at c+ promises/futures in stdc++? there is no cancel for starters. there are > wait methods that we just don't support. you CAN'T map an eina_promise or an > eo_promise to c++ promises/futures. they are disjoint sets. I don't know why you think that's the only way. First of all, if Eolian can generate, why then bindings writing manual code couldn't? I think you're confusing by thinking I have to instantiate a std::future/std::promise for this to be useful and/or used by C++ developers. future/promises are part of the STL, which means Standard _Template_ Library, so the concrete type doesn't have to one from the std:: namespace, I can create one myself and that will be used just the same. This is exactly how all of eina is bound to C++ right now, I do not return a std::list, but a efl::eina::list, which _is_ a list container, i.e. it models the Container concept from the STL, however it has more push_back/insert/etc overloads that also accept a naked-pointer or std::unique_ptr for transferring ownership, and treat value_type as T and not T* (it is like the boost.ptr_container library). Spite of it being a different type and having some differences, it works exactly as the user expects and can be used with all STL algorithms. That's exactly how efl::eina::future/promise will work. We will have a efl::eina::future and efl::eina::promise class templates that will wrap the Eina/Eo_Future* handle/object. They will not, and cannot, be exposed directly, specially for C++ where it will be a template and not a C++ class, otherwise we will have void* all over the place and that would _really_ _really_ suck in C++ to use void*. For JS it will be exactlly the same, it will not return a new Promise(), but one that will be manually bound to have the same API + things we extended it with. The class will be a 'thenable' (https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise/resolve#Resolving_thenables_and_throwing_Errors) and will interoperate with normal JavaScript code that expects ECMAScript Promises. So whoever uses our code will be able to cancel _and_ do the things they are used to with a Promise. It is true they are all different, however, over a solid, well-defined, asynchronous primitive we can build all the translations. Lua is quite different, and IMO, that's what will make it even more awesome. For this to work, the binding will just generate differently when it sees a promise<T> in the method, the generated method will call a eina/eo_promise_then on the promise that the C function will return with a callback notifying the current coroutine can be scheduled to resume and it will do an immediately yield. We should probably have a cancel function on couroutines as well in this case so we can cancel the whole co-routine which will cancel the currently pending promise. The cancel could resume the coroutine with a lua_error, so the coroutine can clean itself if it needs. So, if you think some of these methods will not work, you will have to be more specific on why. Because to me, right now, that's the only sensible solution if we really want people to use our bindings with asynchronous operations. [snip] Kind regards, -- Felipe Magno de Almeida ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
