2016-09-25 4:37 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > On Sat, 24 Sep 2016 18:44:28 +0200 Davide Andreoli <d...@gurumeditation.it > > > said: > > > 2016-09-24 12:59 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > > > > > On Sat, 24 Sep 2016 12:43:03 +0200 Davide Andreoli < > d...@gurumeditation.it > > > > > > > said: > > > > > > > 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 > > > > > > difference - promises are temporary/transient and dont tend to stay > around > > > a > > > lot. callbacks hang out on objects by the 1000's and hang out all day > like > > > a > > > bad smell... :) > > > > > > > > > > > > > > > > > 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 > > > > > > maybe we should use a whole struct that holds cb, data and free cb. > maybe > > > thats > > > a bit much? like > > > > > > typedef struct _Efl_Callback Efl_Callback; > > > typedef void (*Efl_Data_Free_Cb) (void *data); > > > > > > struct _Efl_Callback { > > > Efl_Event_Cb func; > > > const void *data; > > > Efl_Data_Free_Cb data_free; > > > }; > > > > > > as now we have a "bag of data" that represents something to call, what > to > > > pas > > > to it and how to clean up what is passed. it is a unit of data and so > > > expressing it as a struct might make more sense, so now we > > > > > > Efl_Callback cb = {my_cb_func, my_cb_data, my_data_free}; > > > efl_callback_add(obj, EVENT_TYPE, &cb); > > > > > > > > I cannot see the benefit of using a struct here... it's more chars to > type > > and more data > > to store when more that one callback is used, like in efl_future_then(), > > where > > we have 3 callback pointers but just 1 *data and 1 data_free_cb > > well before it was 1 values always together. a func ptr + data ptr, now > it's 3 > values. together. always. doesn't it make sense to start grouping them as a > unit? i dislike havin to pass yet another NULL all the time too. the > number of > times that data pointer needs freeing is rather rare (in my experience). >
I'm also not so happy to add yet another NULL to type, but I really cannot see how your proposal will improve things, especially for efl_future_then() :/ You want something like this? f = efl_uri_set(url); Efl_Callback cb1 = {my_done_cb, my_cb_data, my_cb_data_free} Efl_Callback cb2 = {my_error_cb} Efl_Callback cb3 = {my_progress_cb} efl_future_then(f, cb1, cb2, cb3) instead of this: f = efl_uri_set(url); efl_future_then(f, my_done_cb, my_error_cb, my_prog_cb, my_cb_data, my_free_data) You are confusing me :) Another solution in my mind would be to leave efl_future_then as is (6 params) and define an efl_then() variadic macro that accept from 3 to 6 args (I'm not sure about the exact syntax here) > > -- > ------------- 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