On 3 June 2016 at 15:42, Carsten Haitzler <ras...@rasterman.com> wrote:
> ok. interacting with promises... > > these are just a mess. > > 1. the value thing is just odd. > 2. they are complex to set up inside our api (setting them up setting > cancel > cb's and more) > 3. they totally screw with what eo and interfaces was all about - making > the > api EASIER to use. promises make it harder. > > why harder? longer lines of code with more parameters and more special > casing... but the WORST... > > void _cb_promise(void *data, void *vaue, Eina_Promise *promise) > > that's a promise cb > > Eina_Bool _cb_event(void *data, const Eo_Event *event) > > and that's an event cb. they are different. eo events were meant to > simplify > and unify our callback handling. to have a single cb signature. now > promises > break that. this is just bad. > That's bad. Doesn't look good. > i wasn't sold on promises. i was skeptical, but whatever... but now i am > seeing > they are visibly making things worse. code is harder to write, harder to > read, > harder to maintain, harder to get right. now we have timeouts that cannot > repeat. no - creating a new timer in the cb is not repeating. it has to > repeat > with the "zero time" being the time when the timer was ticked off, not > "now". > > please - everyone. take a look at promises and how they are used. forget > all of > the "but node.js has them" and all the "i can chain promises" and so on. > the > BASIC usage of them is harder now in efl. > > what to do? well... minimize their use for one. do not use them unless you > ABSOLUTELY HAVE TO. also promises should become eo objects with event cb's > so > they work just like everything else. i can ref, unref, delete and whatever > them > like everything else. > > right now i think promises are just not in a shape to use or ship. they > need a > lot more work. i think we need to drop them for efl 1.18 and defer for efl > 2.0 > I also haven't understood the data stuff. value vs data, and which to pass where. My problem right now is I basically can not use efl_loop_timeout. p = efl_loop_timeout(evas_obj); --> p is NULL p = efl_loop_timeout(eo_provider_find(evas_obj, EFL_LOOP_CLASS)); --> p is NULL because evas_obj is not able to find the loop (not a Loop.User) p = efl_loop_timeout(ecore_main_loop_get()); --> p is valid. But I just called a non EO API. oops Now I want to cancel my previous timeout to renew it from "now": eina_promise_cancel(p); --> crash if p is NULL (2 most convenient cases above) --> crashes later if p is valid... but the timeout cb is still triggered (bug) Basically promises as they are right now are incredibly unsafe. Any misstep will crash. Last point is: ecore_timeout takes one line only to create the timeout, efl_loop_timeout takes two lines (create promise + use it). Less convenient. Best regards, -- Jean-Philippe André ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
