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.
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: 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. 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. 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. The separation between Future and Promise, IMO, is good. About the runtime-checking, I think there's a misconception here. Eo is about runtime-checking indeed. But Eolian is about generating interfaces that are not necessarily runtime-checked. C++ is _not_ runtime-checked. So, if things belong to multiple interfaces, then it should be in two different interfaces IMO. Otherwise C++ programmers will assume they can value_set 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. 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
