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. > 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
