On Sep 17, 2016 3:53 AM, "Davide Andreoli" <d...@gurumeditation.it> wrote: > > 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:
The problem with callbacks is not difficult to implement, but difficult to free the void* data. It needs two function pointers and the void* data to implement correctly and generally. Not that I'm against per se, but lifetime is the real problem. > 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 ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
