On Mon, 26 Sep 2016 16:31:43 -0300 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> 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. that's actually my concern. right now the amount of code across efl that has to track that void * to cb's and free it is highly rare, if at all, BUT maybe this is because we've avoided this kind of code because it's painful/work to have to free it, so we "do it another way" instead. but your point here is what's in my thoughts. how useful is this really vs the cost of yet another parameter to p [ass (mostly NULL) and have storage for (4 or now mostly 8 bytes per cb). > 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. yes. but IF we do this.. we need to be consistent and so also do it for event cb's too. that means another func ptr there. in fact i see the use MORE for events than promises and promises guarantee to call success or failure once and once only. events may be called multiple times or never, so there isn't a clear "cleanup" point like futures/promises which have the then/else cb points. for a regular event the cleanup is when the callback is removed (either by callback_del or by deletion of the object itself). > -- > 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 > -- ------------- 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
