God, walls of text. :) I think you are confusing a few things which is where your disagreement with raster comes from. More on that below.
On 16/06/16 01:28, Cedric BAIL wrote: > 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. As raster said, you can use @protected for that. This is a very good example to why protected exists in languages like C++ and in Eo. Protected means: do not call this function if you are not the one implementing this class, inheriting from it, or in eolian we also added: managing the object, because C is different. This is a prime example of where protected should be used, and with only one object. If you want, another thing you can do, which is a pattern I've used before is something like this: Efl.Promise.Future Efl.Promise.Owner - inherits from Future and extends it to add the aforementioned management functions. You create an Efl.Promise.Owner internally, but return it as Efl.Promise.Future. It won't really matter in C, but in bindings they'll see the type as Future, so they won't have access to the functions. I like the protected approach better in this case. > >> 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. This is the confusion I was referring to earlier. Eo.Base was also not always automatically bound, but using eolian to create the class and expose the functions is still useful. Eolian is great, we use it for docs generation, simplification of code and etc. Use it, just add special treatment in generators, that is absolutely fine and not mutually exclusive. > >> 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. > Didn't understand this statement. -- Tom. ------------------------------------------------------------------------------ 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
