On Wed, Jun 15, 2016 at 4:25 PM, Carsten Haitzler <[email protected]> wrote: > On Wed, 15 Jun 2016 13:41:06 -0700 Cedric BAIL <[email protected]> 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. > 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 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. -- Cedric BAIL ------------------------------------------------------------------------------ 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://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
