On Mon, Jun 20, 2016 at 12:06 AM, Carsten Haitzler <[email protected]> wrote: > 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] >> 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. We can't be arguing C++ API because users won't read a header file. This is not reasonable. Do we expect C developers to read documentation, or at least doxygen docs? > 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. They will be glad their application didn't deadlock. std::future<T> can deadlock too on wait. At least ours will warn then. Also, std::future<T> might throw the same exception if the same thread tries to lock the same non-recursive mutex. Exceptions exist to interrupt a function to finish which can't guarantee its post-conditions, which would be exactly the case. > lua has no syntax at all for promises. coroutines are nothing of the sort. I have implemented coroutines for Lua already, you can check it at https://github.com/expertisesolutions/ghtv-ncl-player/blob/master/src/ncl/lua/ It is a partial implementation I wrote of the interactivity system of the Brazilian Digital TV system I did back in 2012. I'm not unfamiliar with co-routines. I know how they work and I know how to implement them and how to extend/sandbox it. The Lua manual shows that a coroutine object is returned, that object can have a cancel function in it. https://www.lua.org/manual/5.3/manual.html#2.6 And to my knowledge, I don't see any problems with using promises and adding a cancel function to the coroutine object. >> 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. IMO, we aren't because each language uses containers in a very different way. And if performance wasn't an issue, I'd still argue the same thing for manually binding containers as well. They _have_ to be manually bound because they are used in very different ways and _should not_ be blindly OO-based. >> 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. Then the binding just calls then on the promise and use that for the Eina/Eo Promise Owner. Though, IMO, we could just prohibit passing @in promises in EFL API and that's it. They would be an @out/return only. But we can just as well create an Promise_Owner from a normal promise as well. [snip] >> 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. If they are the same thing, how are they so different that you think they can't even be translated to that? >> 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. Any Lua function can "throw" an error. A cancelation would be just an error while calling a function that returns a promise. >> 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. Is sockets related to coroutines? Why do they handle it that way? Because it is the _Lua-way_. Why are we so special? >> 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. We will not miss wait, cancel or progress. Anyway, we can have an Eolian promise object and just manually bind it to other languages when the time comes. At least with Eolian, we can change our minds later one way or another. > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
