On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida > <felipe.m.alme...@gmail.com> said:
[snip] >> 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. There will be wait. I'll implement it. It will throw an exception if it is called from the mainloop thread. And people will miss cancel if they don't look for it. They will miss it too if they use Eo_Promise too and don't look for it. > 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. It doesn't matter it is a disjoint set as long as we have a powerful primitive, because we can translate that to every other language. If, however, we impose a broken concept for that language, nobody is going to use it. That means events for asynchronous operations and ad-hoc implementation of it for every asynchronous operation. >> 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. It will. >> 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. That is _exactly_ the same as manually binding. I don't see how that is any different. Besides, there are difference of syntax from C++, JS and Lua, so makiing it a single class automatically generated is not better at all in this case. Why don't we just generate all eina containers too? We could be arguing exactly the same thing. >> 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. Who cares? It is dynamic typing. How do you even _tell_ it is not a Promise? It will work the same, quack the same and even smell the same. >> (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. I don't get why promises should have a concept of yield? Yield is a concept of coroutines. It means it is not ready to make progress and something else should run in its place. Promises can't have yield because promises make no promise (pun intended) of that. However a co-routine _using_ promises know when progress can be made when the promise tells them. > coroutines have no concept of fail, cancel, progress. It does for fail, as I've explained in the last email. For cancel it is just a failure as well and asking for cancelation can be just a meta-method on the couroutine. And progress can be just a function that the asynchronous call will get it. > coroutines are a wrong match. just because they run code later > doesn't mean they match a promise. it is the _perfect_ match IMO. Probably we should ask someone that actually uses Lua about it, instead of guessing. > 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. That's not the job of promises, the job of promises is being a primitive that bindings can abstract it. If you make it a uber_super_solution_for_async, then obviously it can be used as primitive. The way it is right now it is the perfect well-defined solution for being a primitive for all the bindings we just discussed. >> 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 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
