On Wed, 15 Jun 2016 17:28:07 -0700 Cedric BAIL <cedric.b...@free.fr> said:
> On Wed, Jun 15, 2016 at 4:25 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Wed, 15 Jun 2016 13:41:06 -0700 Cedric BAIL <cedric.b...@free.fr> said: > >> Ok, I am giving up on this. We will make it an eo object, but not an > >> eolian one as it should be a native type for any binding (It is sure > >> that C++, Lua and JS will have to do a manual binding for it) as there > >> is very little case were inheritance make sense on promise and > >> wouldn't at the same time break binding. eina_promise_owner will > >> become eo_promise and eina_promise will become eo_future (to follow > >> C++ naming convention). Not to sure how to limit the interface exposed > >> by a return type as we don't want the user of the API to access the > >> promise API, just the future one. Double object would be annoying, but > >> is likely the only solution. So if we want to be safe, we will need to > >> use 2 objects per promise. One facing the user of the API and one used > >> by the producer of the API. If we don't want to be safe, we can merge > >> both API and just use inheritance. So returning an eo_future interface > >> in the API, while in fact eo_promise function would work on it. > > > > what api should not be used? a lot of not most will need to be bound and > > exposed so you can CREATE a promise - e.g. if you create a new class in js > > and want to return promises or set them up etc. etc. > > There is two part to a promise. C++ is clearer on this. It define one > side to be the promise and the other to be the future. The future is > what deliver the value. You can cancel it and it is what you actually > get from any API that provide something using promise. Promise is what > the owner, the creator of the promise use internally to set value on > or trigger cancel. The user of the future is not supposed to ever call > value set on the future. This is for type safety obviously. well the functions have to exist either way so you can set them up. as tom said - divide into a owner/future interfaces on a promise object for example, or use @protected for those funcs we only use on the c side etc. > > and why not eolian. eo base uses eolian. you can make methods @protected for > > example... and why not inheritance? adding progress events to me at least is > > taking the basic promise without them and extending by adding. it's even > > then typesafe in c++ - you cant listen for progress on a promise that does > > not provide it. we don't do it right now but for events we could also type > > check in c too to see what events that class supports and runtime > > error/reject. > > As said, you can not automatically bind a promise. It is a native type > for every possible binding. It also make little sense to actually as toms said - still use .eo files and eolian_gen ... :) and yoou can partially bind it with eolian just like eo base class is. > inherit in that case as that inherited type would be unavailable to > any binding obviously. Following C++ naming, future are defined by > having 3 events (then, cancel and progress) with a guaranty that > either then or cancel will happen. As for promise, they allow the > delivery of a value that may be associated with some progress and can > also fail. The scope of promise is well defined and has been used like > this for years in other language (It even managed to land in C++ and > JS standard). > > Also this is part of the language of eolian. You define a promise that > return a future value, like promise<something>. Promise is a future > container to that type. As stated above, binding will have no clue > what to do with a a new container that they have never heard off. > Especially if there is a new behavior needed to be implemented to > finish the task. If a promise is not defined by then/cancel/progress, > it is likely to break its integration with _all/_race and any module > that use promise in any bindings. Basically if you add undefined > event, that promise is unusable in any binding. > > > if you now need not just progress but some other event along the way to > > completion, just inherit class and extend. > > It is most likely that you are trying to squeeze 2 promise into one or > something that is not a promise to a value, but something else. eh? i'm just speaking of the progress thing in eina_promise. that can be done with a progress promise class that inherits from a basic promise class. it adds progress events (and that's about it) in normal eo fashion. :) you could make it part of the basic promise class too, but it's an example of how to extend the promise class to do more. -- ------------- 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
