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) 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. > 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 ------------------------------------------------------------------------------ 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
