On Sat, 25 Jun 2016 10:28:37 -0300 Felipe Magno de Almeida <felipe.m.alme...@gmail.com> said:
> Hello, > > I still don't get it why promises should be an all-or-nothing thing. It must > be usable for all scenarios possible or we should drop it and > live with events which are impossible to translate to the real semantics > of asynchronous operations (I'm calling an asynchronous operation > one that returns a value asynchronously) to bindings that already have > a concept of asynchronous operations. i don't know if anyone said it should be all or nothing. i have said that given the newness and disagreements on promises that we need to use them very carefully and avoid usage "all over the place" for now until we can settle them down. if we were all happy with them and agreed on them then things may be different, but that is not the case. i think a big difference is our view of promises. to me a promise is an OBJECT that REPRESENTS the async action (and then is responsible for calling the correct callbacks and for storing the value until all such callbacks are called etc. etc.). you (and cedric) keep referring to promises as async values. at least in every language binding they are OBJECTS. they have methods on them (p.then(), and to cancel p.cancel() for starters). > One example is making promises open to add new events through > inheritance. However, let's say that it is really desirable, so we can > all compromise on a middle term, we need to have a way to support > that in bindings in a way that is natural in the binding languages, and > IMO that is the _most_important_part_ and I have been repeating > myself about this since I introduced the promise idea in january, but > let me repeat again: yes, and since promises are objects in every language and binding we support... this isn't much of an issue. we can extend progress events as eo events since they wont be a minimal base requirement. will these events be really common? good question. at least in our current usage progress is not used, so... why not extend that via eo events? this would work in every language we bind to as long as we return the promise objects from our api's (they will be of the right type then with these extensions). the natural bindings in c++ (libstdc++) have no progress, so when we add this - our promises are not 1005 natural. this is something we have to accept, OR we will require efl to be the lowest common denominator of all languages and that would be far worse then even just using events on objects for async work. > Promises must be a way to have well-defined-semantics for bindings > to be able to translate that to what is natural and native in the binding > languages. The whole efl interfaces effort, afaik, is not about C API, > because we already have a stable C API! We need to think about > bindings too, because the efl interfaces effort is, afaik, about having > usable efl interface api for bindings, which we don't have yet. We > can't create bad C APIs in the process ofc, but, afaik, this is not > about creating new C APIs. actually... efl interfaces started to improve/clean our c interfaces. bindings came later. but i agree with you that things like promises need to map to bindings nicely. they ALSO have to be nice in c. if the bindings are done manually for other langs then we need to focus on making the c api nice. as long as this does not PRECLUDE manual bindings from making promises work in the language native way. that's why i don't see that e HAVE to split promises in c into owner/future. that can be done manually in the bindings *IF* the language does a split. js does not. c++ does. java does. lua has no promise so it's whatever we decide (likely the js way). but in C there is no real point in splitting between promise owner and future. > I work on most bindings for EFL, so yeah, I'll be very annoying about > it, because I don't want to create bad bindings. I don't think anybody > wants to work to do bad things, I'm not different. I want to be > proud of what I deliver. And that means writing bindings that people > will want to use, and not that people will curse me because they > _have_ to use it. Also, I think it will help EFL a lot if we get it > to be used by more languages. see above. i agree. but we cant go fucking up our c api as a result. > So, bindings already know the special relationship between derived > classes of Future (I'm using cedric's nomenclature here) and > translate new events directly. So I think this is doable. With the > lifetime thing, well, for bindings I don't care if we drop it any > automagical things because bindings will deal it correctly. So > that makes things easier. Implementing data models in C > might be a little less sexy, but still way easier than using events > and caching all things and etc. if the model objects do NOT cache data like properties... they are going to be so horrible in performance... it's not funny. any re-fetch of a property by the ui for example will need a complete re-fetch from disk/network/whatever. no - model objects really need to cache property data. > The separation between Future and Promise, IMO, is good. at least in c it doesn't help us much and only complicates our code where we have to fetch future objects from promise objects etc. - since in C our typechecking is runtime, then do it the js way because that is what makes sense. it is simpler. > About the runtime-checking, I think there's a misconception here. > Eo is about runtime-checking indeed. But Eolian is about i know. i'm speaking of the c api here. not c++, js, lua etc. - we dwont get typechecking at compile time in c without c understanding inheritance for structs typedefs etc. > generating interfaces that are not necessarily runtime-checked. > C++ is _not_ runtime-checked. So, if things belong to multiple i know. and since you ant the bindings to be manual - then separate in c++ into promise and future and presto. at the c++ api level you have a specific type. that wraps the same c efl promise object though. :) isn't that easier? > interfaces, then it should be in two different interfaces IMO. > Otherwise C++ programmers will assume they can value_set ^^^ as above. manual binding solves that. it does keep the work of supporting a language higher though. > a future/promise they received from another function. And > sometimes they will be right, it is not prohibited to return > promise_owners and it was an idea that almost worked for > genlists to get style from through events, it just didn't work > because genlist must get the style synchronously and not > asynchronously. So, separating the side that value_set > from the side that listens to value_set makes things > way clearer of the API intent. > > However, as long as it uses different nomenclatures in > Eolian, I can separate them in C++ in generation. that was what i was saying. have a promise object that inherits from a promise owner object. the promise owner api is for the owner, the promise api (or future api) is for the promise user. it's then clear which methods are for who in c. and in c++ you can easily split this up as you say. for js and lua there is then no point splitting as js doesn't split and as lua is similar, there is no point there either. > Regards, > -- > Felipe Magno de Almeida > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > 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 ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
