On Mon, 26 Sep 2016 14:23:39 -0700 Cedric BAIL <[email protected]> said:
> On Sun, Sep 25, 2016 at 1:59 AM, Davide Andreoli <[email protected]> > wrote: > > 2016-09-25 4:37 GMT+02:00 Carsten Haitzler <[email protected]>: > >> On Sat, 24 Sep 2016 18:44:28 +0200 Davide Andreoli <[email protected] > >> said: > >> > 2016-09-24 12:59 GMT+02:00 Carsten Haitzler <[email protected]>: > >> > > On Sat, 24 Sep 2016 12:43:03 +0200 Davide Andreoli < > >> [email protected] > >> > > > > >> > > said: > >> > > > >> > > > 2016-09-24 7:14 GMT+02:00 Carsten Haitzler <[email protected]>: > > <snip> > > >> > > 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) > > I guess he had something in mind like what we do with > EFL_CALLBACKS_ARRAY_DEFINE (We can't use static directly as this would > break on windows). So it should look like : > > EFL_FUTURE_DEFINE_THEN(name1, done_cb, error_cb, progress_cb, data, > data_free_cb); > EFL_FUTURE_DEFINE_PROPAGATE_THEN(name2, done_cb, data, data_free_cb); > > and you would do : > > efl_future_then(f, name1()); > efl_future_then(f, name2()); > > Arguably we could do the deduplication inside efl_future_then, but > that does had a lookup in a hash table and will likely impact speed. > This does the lookup for us at compile time, which is better, but I > don't really like the API. > > > 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 :) > > I agree with you, we are already paying the price of using Eo here, I > guess we do not care that much about memory and speed anyway (Do not > forget that we do have a full fledged Eo object allocated per future > here, this is way more expensive than 3 pointers). So should we make > our API that much worse for a gain that will be impossible to see ? If > we move future to be their own object, or use an Eo light object, > maybe that would make sense, but otherwise, I think we are missing the > point here. We want a nice API ! > > > 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) > > I am not a big fan of variadic and this would still push for doing > deduplication at run time, so not a big fan and I am pretty sure it > doesn't really help with any real problem. my reasons have nothing to do with deduplication at runtime - that can be done regardless. it's just the continual grown of more and more parameters for a function call. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
