On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida <[email protected]> said:
> On Sun, Jun 19, 2016 at 7:22 PM, Carsten Haitzler <[email protected]> > wrote: > > On Sun, 19 Jun 2016 14:21:28 -0300 Felipe Magno de Almeida > > <[email protected]> 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. there';s a difference. if it's a std promise then they expect it to work a certain way. if its an efl one they need to learn its api and behaviour. they will find the features. > > 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. we can't to lua - it has nothing even close. we have to build it specifically. > 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. and when they get the exceptions thrown they'll complain that it's broken. there is an api exposed that is meant to work, but does not. > >> 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. lua has no syntax at all for promises. coroutines are nothing of the sort. > Why don't we just generate all eina containers too? We could be > arguing exactly the same thing. because promises are objects with ref counting, callbacks, lifespan etc. they are being USEd to replace objects like job and timers (as a timeout). making lists objects would be a huge memory footprint jump. not so with eina_promise vs an eo version of it. they also are not used and stored 10000's of times in an app unlike let's say eina lists. > >> 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. it depends if you return it or have to create it and pass it in. if its create and pass in like is used in efl_model and now fileselector then you have to CREATE the correct type in your js code to pass in. > >> (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 you are talking of using coroutines as promises. if you want a cancel on a coroutine .. that is exactly what you are talking about. the coroutine represnets the promise. same thing. > 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 where? the lua docs on coroutines show no failure. just run until completion or a yield, then pick up where the yield left of if run again. there is no separation of success or failure segments of code in coroutines. promises explicitly want a difference. > 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. not if created as a normal coruotine. and why shove a square peg in a round hole? coruotines are not related to promises. they are different beasts. just create full promises in lua with a then+fail function with closures like in js etc. etc. > > 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. it's not. wait. cancel. .... i've listed them. we end up extending language promises and/or futures but then eg missing features like wait. if passed in like they are as above then we have issues... etc. etc. etc. > >> 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) [email protected] > > > Regards, > -- > Felipe Magno de Almeida > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
