On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida <felipe.m.alme...@gmail.com> said:
> 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). and having an efl::promise and efl::future will miss features from the std one's like wait. someone used to the std ones will be confused. as to their usage.. someone used to th std ones will not know they can cancel. you have created your own promise type effectively. it may be similar to the std ones, but it is a new object in its own right. that is exactly what i said. and that is why i was saying that efl promises in all languages will be special efl promises as efl promises are a disjoint set from just about every other promise/future thing i looked up. > 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. wait doesn't work. > 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*. that is probably something eolian_gen needs to know - iv you accept or return void *'s it needs to generate a template for that class. > 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' that is exactly what i said. and so it's now some Efl.Promise class, not a Promise. > (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. coroutines are BARELY a match for promises. they simply execute code later. our promises have no concept of yield. coroutines have no concept of fail, cancel, progress. coroutines are a wrong match. just because they run code later doesn't mean they match a promise. what eina_promise is is a far far far more extensive blob of code that does not let you yield and pick up where you left off. we would want to create fill promise objects in lua that actually match what efl promises are. > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
