On Thu, 16 Jun 2016 19:38:55 +0100 Tom Hacohen <[email protected]> said:
> 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 <[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. > > 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. i agree too. though maytbe splitting it in eolian/eo files makes sense so the future is what you see as a recipient of a promise but in c it's just the same object and we have promise methods and future methods that work on it. c will be happy. for c++ if you get a future, the promise methods should be protected. creating the promise still needs another set of api's. the same object just has 2 views. a view as a promise (to the creator) and a view as a future (the consumer). but either way the methods will have to exist in bindings so you can set up promises 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 > > 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. yeah. eo base is not totally auto-magic. callbacks are special cases handled. promises will likely need/want this too - maybe not use eo callbacks for then/else but a special 2 cb method like i mentioned before. it doesn't add a cb but sets it. it can be set just once (more calls to it after first setup fail). > >> 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. i didn't either... :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
