2016-09-21 4:35 GMT+02:00 Felipe Magno de Almeida < felipe.m.alme...@gmail.com>:
> On Sun, Sep 18, 2016 at 3:35 AM, Davide Andreoli <d...@gurumeditation.it> > wrote: > > 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: > > [snip] > > >> 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? > > Promises are not generic, so their lifetime is known. The user frees it in > success/failure callback, yes. > ok, thanks for the explanation. So the user have to free the *data in both success and failure callbacks... this is error prone and repetitive for the user, I suggest instead to add a free_data cb, in this way the usage is simpler and it also correspond better with the promise_value_set that already have the free callback. > > > What about chained promises? > > Chained promises are multiple promises, so each success/failure callback > that is registered must free its void* data in its own success/failure > callback. > yep, you right, again thanks for the clarification. > > Note that the void* data is in this case in efl_promise_then, and not in > efl_promise_value_set, the last one has a free callback for the value. > As I said just above, better to have the free callback in both API. > > [snip] > > Regards, > -- > Felipe Magno de Almeida > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > 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
