On Sat, Sep 24, 2016 at 2:14 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Fri, 23 Sep 2016 17:24:17 -0700 Cedric BAIL <cedric.b...@free.fr> said: > >> On Fri, Sep 23, 2016 at 10:48 AM, Davide Andreoli >> <d...@gurumeditation.it> wrote: >> > 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. >> >> Hum, we are talking about the data pointer given when registering the >> callback right ? I guess it would make sense and simplify a lot of >> code. Should we also apply that on efl.object events too ? >> >> In that case, if NULL is given, nothing will be done on the pointer. >> Are we ok with this ? > > ummmm right now we provide in C a void * for cb data. what this is is unknown > to efl and if you want a free cb we have to pass ANOTHER pointer to the free > cb... and this also means STORING these ptrs too along with every cb. do we > really want to spend this extra ptr? 8 bytes on 64bit... per cb... extra. > > i see the point, but i also see the cost. :/ > > if we do this - we do this for promises AND efl events. must be > symmetric/everywhere.
we must consider that, at least for promises, the "fulfillment" cb often doesn't free stuff, while the "rejection" does... Thus this extra CB won't be that useful. more often than not these "void *" are some existing context, like "private data (pd)" or some other object. In some cases these have longer lifetime than the promise (they contain it, and would cancel it when they are deleted). Thus the free_cb will not be that useful as Dave thinks. providing a function on your own and calling it from both reject/fulfill cbs when its the case its simpler and saves memory. however, documenting this behavior must be done so users do know what happens and what should be cleaned. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
