2016-09-18 4:30 GMT+02:00 Felipe Magno de Almeida < felipe.m.alme...@gmail.com>:
> 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. > Indeed the lifetime of the *void data is the trickiest part, a free_data_cb seems to me the most "correct" way to handle this, not only for bindings but also for C code. Can you explain me how promises solve this problem? where the user is expected to free the *data in C? in both the success/failure callbacks? What about chained promises? > > > 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 > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
