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 ?
-- 
Cedric BAIL

------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to