On Sat, 18 Jun 2016 23:06:35 -0300 Felipe Magno de Almeida <felipe.m.alme...@gmail.com> said:
> On Sat, Jun 18, 2016 at 10:56 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Fri, 17 Jun 2016 11:12:51 -0300 Felipe Magno de Almeida > > <felipe.m.alme...@gmail.com> said: > > > > felipe - look at eina promises then loo at stdc++ promise and futures. they > > dont even match. js promises cant be canceled. lua doesn't even have the > > idea of a promise. what we have in eina_promise doesn't translate to any > > language native future/promise thing. it's very specifically an efl thing > > and if we do it we need to embrace it as such and that's how it goes. it > > LOOKs like many language native promise things but it's extended and efl > > specific. that's the on;y way to use promises we have, otherwise we should > > drop them entirely and do things only by obj + event cb's because this > > problem space is just too fragmented with the lowest common denominator not > > being even good enough for us (no cancel) but not even being enough for > > other langs (c++ has wait - we don't) > > 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. > exactly as JavaScript developers are used to, but they will have the option > to cancel as well, and C++ will be able to wait on it or register a callback how? where? without the promise being an object... how? because in js they are promises. in c++ a promise and future are... objects. > function. And for Lua exactly how I explained in the email below. Maybe you > missed my answer to your reply in the bottom of the email,after my answer > to Tom? i saw you spoke about coroutines. but that is not what a promise is in efl. there is a definite handle you have to have to be able to address it. lua have NO promises themselves of any sort. nothing. there is nothing to even have a cancel method on for example. > > so as you said - then make promises full efl supported objects and they > > appear so in every language and work the same way, as the only other option > > is to drop them entirely. > > I neveer said that. And for the reasons I explained below. >> So, in the end, if we make Promises an Eo/Eolian >> object with very well defined semantics, we get >> a "normal class"* that works the same as an yes - you said in c only - but we have to map what we have in c to other languages. show me how a libstdc++ promise/future is able to be canceled? show me. show me how a js promise does progress events 9without extending the class to a special promise class of our own). show me the promises in lua, or futures or anything even equivalent than can be canceled, listened to for success or failure, even events. > >> So, JP asked my opinion privately and he thought it would > >> be better for me to paste what I replied here. I didn't want > >> to make this discussion longer, however I have to make > >> these points explicit so we can move on. Sorry in advance > >> for the huge email. So I'll paste my answer here and then > >> make some considerations of other points afterwards: > >> > >> "" > >> Hello JP, > >> > >> Now I see I should've voiced myself more in the discussion. But it has been > >> too lengthy and too much things to do before and during the feature freeze, > >> so I kinda absteined myself from it. Which was probably an error because > >> now nobody knows my opinion on the matter. > >> > >> My personal stance on promises being Eo objects is that we're hammering > >> things to be OOP more than it should. IMO, Promises are nothing more > >> than a one-element-containers that warns when the value is available. > >> > >> It is not too much different from Eina_List/Eina_Array, etc. Could we > >> make Eina containers Eo objects? We can, would it have benefits? > >> It would. However, it is always a trade-off and the problems it brings > >> would bigger than the benefits. Java does it and it works, but it slow > >> and invites people to inherit classes in ways they can't possibly do > >> because they, inadvertadly, break the class invariants by changing > >> how the user interacts with the class (by overriding methods). > >> > >> I'm sure in C++, JavaScript and Lua they won't be used as an Eolian > >> class at all, that's even why Kolesa has suggested that it should > >> not even be an Eolian class (but be a Eo class implemented directly), > >> that way people can't inherit from it and bindings don't have to > >> special case the class, like we have to do for Eo.Base. > >> > >> Now, why classes shouldn't generate Promise as an Eolian class? > >> Because it makes no sense and it is _not_ convenient to users. > >> Registering events? What does event have to do with anything? > >> And how do you chain promises like in JavaScript with events? > >> Well, you don't. And how about Lua? Why should Lua even > >> generate a Promise object? In Lua I'd expect the Promise > >> to be used to connect the Lua event loop with co-routines, > >> so the current execution would just get scheduled-out and > >> return execution when the Promise is now fulfilled. > >> > >> The idea that we're going to create the _uber_super_ Promise > >> class for all languages is, IMO, completely impossible. Each > >> language will have its own asynchronous-way to deal with > >> how values are going to be available in the future and which > >> syntax better conveys that concept. Promises in our API, > >> OTH, allow us to _talk_ about asynchronous operations > >> in a way that is well-defined and which bindings can rely > >> enough to do proper code generation without knowing > >> specific semantics of each asynchronous operations. That > >> is not possible with events per se, because bindings > >> don't know anything about them. > >> > >> However, making promises an Eo object is not a problem > >> per se, as long as we have _very_well_defined_ > >> semantics for everything, it works exactly the same, > >> but, at the same time, to have very well defined > >> semantics we need to limit on how extensible everything > >> is, otherwise we just get normal events again and > >> that is not well-defined enough to be translatable > >> properly to every language. > >> > >> So, in the end, if we make Promises an Eo/Eolian > >> object with very well defined semantics, we get > >> a "normal class"* that works the same as an > >> Eina_Promise, but uses the Eo syntax > >> for things on C (only on C!), and with that we > >> start paying for things that doesn't seem > >> to make sense IMO, such as the cost of > >> late binding in Eo; the cost of allocating > >> and instantiating a Eo object; etc. Without > >> reaping any benefits. And, IMO, if asynchronous > >> operations are to be _really_ used in EFL, we > >> need promises to be _fast_. Asynchronous > >> operations already have a inherent cost of > >> having to use heap memory where synchronous > >> operations can just use stack allocation, if > >> we make the cost considerably bigger, then > >> asynchronous operations becomes way too > >> costly to be useful for more and more > >> scenarios, and then it just won't be as useful. > >> Or maybe worse, each sub-component > >> start creating its own way of doing asynchronous, > >> because promises now are too expensive. > >> > >> We can optimize things other ways ofc, like > >> caching and etc. But I fear this becomes > >> another eo_do, where we want to be > >> faster than C++ and end up creating a > >> huge infrastructure to make it faster, > >> and end up being even slower. > >> > >> * not so normal, because we need to be able > >> to mark the type information statically when > >> used, as we do for containers, but that is only > >> on usage, so not a huge problem. > >> > >> So, tl;dr; I think we need to have fast > >> promises so we can use it in more places, > >> have a proper C API that is convenient > >> to use and remove any frivelous features > >> that aren't extremely necessary for > >> normal asynchronous operations. And > >> let bindings deal with asynchronous their > >> own way by being users to EFL Promises, > >> and not necessarily expose EFL Promises > >> directly. > >> "" > >> > >> On Fri, Jun 17, 2016 at 9:38 AM, Tom Hacohen <t...@osg.samsung.com> wrote: > >> > On 16/06/16 22:55, Cedric BAIL wrote: > >> >> Being against promise, is only advocating for no asynchrone behavior > >> >> in Efl. This is a position we can't take. So either you have a better > >> >> pattern to handle asynchronous behavior and synchronisation or we have > >> >> to provide promise. Objecting to promise is clearly not helping > >> >> anything here. > >> > > >> > This is FUD and raster called you out on it a few times already, please > >> > stop stating it as fact all over the place, because it's anything but. > >> > You can say "in my opinion it's better to use promises", but that's as > >> > far as I'll go. > >> > >> It is not FUD, making asynchronous operations ad-hoc with events > >> is not just a huge _pain in the ass_ to implement and use in C, but > >> also makes it impossible to translate that into anything that > >> would properly ressemble asynchronous operations in any > >> other language. Just simply ignoring the relationship that is > >> intrinsic on the asynchronous action and the events that > >> are bound to happen and in which order and how many times > >> they do makes it impossible to convey the information to bindings > >> as an asynchronous operation. All you can do is document things > >> and say, hey, you want to have an asynchronous operation? > >> Then first register events here, here and here first, then make > >> a seeming synchronous operation. This is awful for any language > >> and is even worse for Lua for the point I made about on top > >> and to which I'll get in deeper details below. > >> > >> Asynchronous operations _must_be_well_defined_to_be_useful > >> and be consistent. It _doesn't_ have to translate to the same > >> thing everywhere and should not translate to the same thing. > >> > >> We should not Eolize everything just to get automatic generation, > >> this is being super lazy. We need to offer good bindings and > >> that means translating concepts. What we really need is > >> a simple Promise/Future/Simple-Callback (the simple-callback > >> being the harder one to implement) so we can have actual > >> asynchronous operations and not just some events that > >> happen to return data as result from some operation that > >> looks synchronous. > >> > >> You could @tag the s*** out of operations so bindings can > >> understand things so it is translatable, however, doing so, > >> doesn't remove the ad-hoc-ness of using events(without > >> a well-defined Promise concept). Which means that > >> 1. every class will do it differently; 2. Events are racy > >> by nature, overriding eo_event_callback_add to do > >> something completely different can solve the raceness, > >> but you can't just change documentation/expectations > >> from calling a function that behaves someway in > >> every other class. You're simply breaking the > >> function behavior for Promises and would be doing > >> even worse for several classes without a Promise > >> concept. So code that used to work one way for > >> _all_ Eo.Base classes, now only work for non-Promise > >> ones. Polymorphism is not about changing pre-conditions > >> and post-conditions of functions, but about extending > >> and interoperating with code. > >> > >> So, Promises have to exist some way or another for > >> us to have asynchronous operations, otherwise > >> it will be a huge mess, it actually already is. We had > >> _at_least_ two ways to do async, one by setting > >> a property (which actually suffers from the same > >> problem as your proposal of overriding > >> eo_event_callback_add) which makes another > >> function to behave bizarrely different and which > >> any user of such function must now track. This is > >> not dynamic polymorphism, this is not even a > >> quack-is-a-duck dynamic typing, this is asking a duck to > >> quack and a dinosaur eating your computer instead. > >> And another was efl.model which wasn't even > >> asynchronous at all, it just had a function that asked > >> the data to be cached, there was nothing really > >> asynchronous about it, you just _couldn't_ have > >> asynchronous calculations because all calculations > >> had to be ready for fetching synchronously, all > >> it had was two-phase construction, basically. > >> > >> On Fri, 3 Jun 2016 15:42:00 +0900 Carsten Haitzler (The Rasterman) > >> <ras...@rasterman.com> said: > >> > > >> > here's a rundown of efl promises vs other languages. basically our > >> > promises don't match any other languages. we can't just convert them to > >> > js promises or c+ > >> > + promise+futures... and lua just has NOTHING there in the language. so > >> > here is a table: > >> > > >> > FEATURE | EFL | C++ | JS | LUA | > >> > ---------------+-----+-----+-----+-----+ > >> > create | X | X | X | | > >> > destroy | X | X | X | | > >> > then/else | X | X | X | | > >> > value | X | X | X | | > >> > cancel | X | | | | > >> > all | X | | X | | > >> > race | X | | X | | > >> > progress | X | | | | > >> > get status | X | | | | > >> > poll value | X | | | | > >> > wait | | X | | | > >> > wait+timeout | | X | | | > >> > ---------------+-----+-----+-----+-----+ > >> > > >> > c++ futures/promises have features we don't. ti read up and they don't > >> > say wait/wait_for/until are optional and may not work. they seem to be > >> > requirements. so we can't map promises to c++ futures. it's not possible > >> > because we basically break how they work. > >> > > >> > we can't map them to js because js has no ability to cancel promises. > >> > also no progress too. so these features in core api's break then in js. > >> > > >> > it seems you can't ask if a promise or a future is done yet (without then > >> > blocking and waiting) in c++ or js, nor poll/get the value. (fyi in java > >> > you can poll the state to see if a future is done yet... for example - > >> > java not included above). > >> > > >> > lua has NOTHING AT ALL to map to. > >> > >> I'm not developing the lua bindings so I can't say what is really going > >> to be mapped to. But I can say what I expect it to be by having used > >> Lua in a while and specially in a very asynchronous context (distributed > >> systems). Lua should map to co-routines! It will be the most beautiful > >> binding we will have! > >> > >> You just write normal code, it stops and is descheduled (the binding > >> will use the Promise for that) and it is rescheduled when > >> the callback on promise_then is executed. > >> > >> This is why I'm saying on the beggining of the email that we shouldn't > >> think of promises as our uber-asynchronous-communication-class that > >> will be exposed to everybody. We just need well-defined semantics > >> for asynchronous operations so we can translate it to every binding > >> in the most fucking nice way. People will likely _wow_ at our > >> co-routines in Lua! I'm sure I could at least make the lab that > >> created Lua in Brazil to wow at creating GUI interfaces with > >> co-routines. > >> > >> For C++ I'll just implement wait, no big deal. Can it deadlock? Yes, > >> but this is C++, you can deadlock a future anyway, you must know > >> what you're doing. It will only be really usable in a threading > >> context. The other parts is just new member functions or free > >> functions on the efl::eina::future<T>. We use templates in C++, > >> not OO to represent most polymorphisms, this is exactly what > >> we did for efl::eina::list, efl::eina::array, etc. This is > >> expected for C++. > >> > >> For JS, we will just implement a new class with the normal > >> Promise API with just a few more functions as well, people don't > >> care this is not a "standard" Promise as long as it is a > >> thenable. This works exactly like C++ but it is dynamic. > >> > >> So, no problem at all for bindings, as long as we have a proper > >> Promise concept. > >> > >> For all creation "problems" we just pass a efl::eina::promise<X> > >> to C++, in JS we pass two functions (probably three in our case): > >> a success, an error and a progress function that is called > >> by the code that wants to instantiate a promise. That's > >> the way to create promises in JS. > >> > >> For Lua, it could be integrated to yield. > >> > >> The All/Race composition in C++ can just be a free function > >> that gets multiple futures and return another future with > >> a tuple of all values, no big deal. It would work very nicely. > >> > >> For Lua, you probably won't use all very much because a > >> coroutine is a promise_all instrinsically. The race thing > >> would be a composition on co-routines. > >> > >> All problems can be solved if we define promises as a properly > >> defined concept that can be used by bindings and are not > >> intended to be used by binding users directly. > >> > >> > -- > >> > Tom. > >> > >> 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 > >> > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > -- > 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
