2016-09-24 7:14 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > 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 are really so much into optimization then promise should not be Eo object at all :P > > if we do this - we do this for promises AND efl events. must be > symmetric/everywhere. > I agree with this, we should probably provide a free_cb every time we accept a void *data > > > > -- > ------------- 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 > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel