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).
--
------------- 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
