On 22/09/16 07:55, Jean-Philippe André wrote:
> Hi,
> On 22 September 2016 at 15:34, Davide Andreoli <d...@gurumeditation.it>
> wrote:
>> 2016-09-22 0:45 GMT+02:00 Gustavo Sverzut Barbieri <barbi...@gmail.com>:
>>> On Wed, Sep 21, 2016 at 11:33 AM, Tom Hacohen <t...@osg.samsung.com>
>> wrote:
>>>> On 21/09/16 15:10, Gustavo Sverzut Barbieri wrote:
>>>>> On Wed, Sep 21, 2016 at 5:26 AM, Tom Hacohen <t...@osg.samsung.com>
>>> wrote:
>>>>> [...]
>>>>>>> promise/future should be first-class citizen... as well as iterator
>>>>>>> and the likes. There is a start already, but refinement is really
>>>>>>> needed, like returning an iterator<x> should handle warn_unused,
>> free,
>>>>>>> own... Promise should have its own callback signature, simplified
>> for
>>>>>>> the user.
>>>>>> They can, be, but they will just be provided by Eo. There's no need
>> for
>>>>>> any special treatment in Eo.
>>>>>> Promise signature: you don't need to do it in Eo. I mean, you can
>> add a
>>>>>> special type in Eolian, but Eo itself need not be aware. Also, I
>>> disagree.
>>>>> Do you mean still use Eo's events to dispatch promises?
>>>> Not necessarily, just use the same signature because it's a good one,
>>>> it's extendable, it applies here too, and it's easier for bindings this
>>> way.
>>> It's a good one to who? It's a generic one, for sure, but that doesn't
>>> make it a good one. Promises, for instance, will carry a value, but
>>> it's not immediately available. Even for regular events I don't get
>>> why the object must be fetched from the efl_event...
>> I'm with Gustavo here, reusing the same callback signature for event
>> and promises don't seems to be a good idea, it just make the usage more
>> confusing and more error prone. Having 2 different signature will make
>> the separation line between events and promises more clear.
> I can hear Cedric screaming in despair on the other side of the planet.
> We argued that a single signature was better, as our different callback
> signatures (ecore events, evas events. smart callbacks, ...) were one of
> the pain points of using EFL. Now it's pretty clear some people want to
> reintroduce this with promises vs. events. Gustavo missed these heated
> arguments as he started working back on EFL after those long mail threads.
> Same for why object is in Efl_Event rather than being in the argument list.
> To be fair, promises were supposed to carry a single value only, IOW
> Efl_Event.info was supposed to be the value. No double cast. Thinking of
> it, I'm not sure why "next" isn't in fact a property on the promise itself
> (as it's Efl_Event.object), rather than being awkwardly passed in the event
> info -- there may be a good reason. (see also efl_event_callback_stop).
> Anyway. I'll wait until I can see *exactly* how async operations (image
> file_set in particular) work with promises. Too much arguing about unclear
> details until that is done.

Every word in stone. I'm kind of tired at this point by rearguing 
everything all the time. It has already been discussed to (my) death.


enlightenment-devel mailing list

Reply via email to