2016-09-15 8:41 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > On Tue, 13 Sep 2016 19:53:20 +0200 Davide Andreoli <d...@gurumeditation.it > > > said: > > > I disagree here, really you are saying that only raster use async stuff > in > > efl? > > > > >From my POV efl is (and has always been) a fully async toolkit, and I > use > > lots of async stuff in all my programs: timers, animators, idlers, > > ecore_con, > > ecore_exe, ecore_fd, edje_signals, emotion callbacks, etc... > > > > And to be honest I never feel the need for a better async API... > > well long before promises here was my thought: > > we have async in our api by callbacks. we haven't made things as async as > they > should be - like file_set or evas images, edje objects etc. with some > returning > true/false for initial success. this was a mistake. for eo we should > basically > indicate success later async (if you care), or have a stop-and-wait api if > you > must know now. (obj.wait() ?). > > the real issue is many objects would DO something async and the event name > was > different from object to object. ecore-con was different to ecore-ipc > (though > very similar). elm image different to evas image, different to edje objects > etc. so you couldnt apply a pattern and just dumbly copy and paste to have > your > cb called "when its done". > > so my thoughts were for eo to at least have some core async interfaces > that all > these objects share to do the wait, provide a set of core standard events > etc. > - this would reduce the mental load for developers using such api's as > they can > re-apply the same knowledge directly across multiple objects. > > what i liked is the simplicity - just create the obj (image, edje, server, > etc.) add event cb's you care about, then "do" the action (set file, > connect > etc.) > > promises do bring in standardization like above, BUT they do it with a lot > more > complexity by having another promise object that is created for that > action on > which you then have to listen for the completion or failure etc. > > i understand why technically it has to be this way, BUT it's incredibly > painful > to deal with. i know i'm not the only one using async api's in efl - and > they > are not that hard to deal with, but as above, could do with improvement. > > i'm dubious about promises still. i see value but i also see downsides. i > think > they are such a radical change from what has been proven to work that the > WISE > thing to do would be to use them in a limited number of places for now and > "see > how that pans out". > > > > Please clarify what would be your proposal in that regard as being > > > against new things without proposing a solution is not helping. > > > > > > > I'm with TAsn, I'm against promise. The simple solution I propose is > > that all the async API have the callbacks explicitly given as params. > > we can't as eolian can't GENERICALLY handle callbacks across languages. it > can > only do it for specific special cases - eg event cb's or if you manually > bind > api's. this means tht you need to do this the way i suggested above. create > obj, add cb's for what you care about, then "do" the action via an api. >
This is another key point about the API we are going to design for efl2: are you really sure this is true? really eolian generators cannot handle callbacks in function params? In my experience (python bindings written in Cython and cffi) callbacks are not so difficult to implement, as soon as the callback function is typed and have a *data param. I think we must rethink this hard restriction we are forcing. There are lots of places where callback functions are useful, also outside the async scope we are discussing now, for example: elm_object_tooltip_content_cb_set() elm_slider_indicator_format_function_set() elm_entry_markup_filter_append() and more I cannot remember right now. How can we implement those functionality if we don't allow func callbacks? > > > And a note: > > I was trying to keep myself out of this promise discussion, but it > > seems not really possible :) What I can say is that I will not discuss > > about the internal implementation of asyncs/promise, I will only argue > > about the API we are going to expose to the user, and I will fight > > for keeping the API as simple as possible. > > the reason i reply to this is, 1. don't keep out of this discussion as > this is > a key core design decision and keeping out just means you'll have to live > with > whatever you get - fine if you just don't care. you care. :) > > and you are taking the exact correct approach. think of it from the api > USER's > point of view. for eo+eolian and on we have to consider multiple languages > too. > c, c++, js, lua, python (in future)... it has to be sane/nice across all of > these. you are coming from the right view here that "think of the user" is > key, > not the implementation. > > ... > > so my take is what tasn said - let's TRY promises in SOME areas and see, > but > let's not go all-in on them. what "some areas" are is a bit fuzzy though... > it'd be good to discuss where we should use promises for now and perhaps > have > an alternative way of doing the same thing and see which one people > gravitate > to... then again having 2 ways to do the same thing is confusing > especially to > newbies... :( ARGH! > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
