On March 14, 2018 12:12 PM, Gustavo Sverzut Barbieri <[email protected]> wrote: > On Wed, Mar 14, 2018 at 2:50 AM, Carsten Haitzler [email protected] wrote: > > On Tue, 13 Mar 2018 10:35:15 -0300 Gustavo Sverzut Barbieri > > [email protected] said: > > > On Tue, Mar 13, 2018 at 1:17 AM, Carsten Haitzler [email protected] > > > wrote: \[...\] > > > > > > > > > > > > for instance, with events rarely we carry payload info, > > > > > > > > > usually one > > > > > > > > > queries from the object... like text changed on widgets. > > > > > > > > > however for promises, with the chaining idea, rarely you > > > > > > > > > should be > > > > > > > > > getting the owner object... in the rare cases you need it, > > > > > > > > > use "the > > > > > > > > > closure" (void *data), which BTW is specific for each future > > > > > > > > > in the > > > > > > > > > chain, then you can chain multiple and "pass thru" the value > > > > > > > > > if you > > > > > > > > > need multiple objects (ie: say you need to get a value and > > > > > > > > > show it > > > > > > > > > to 2 label objects, you can connect 2 cb in a chain, each > > > > > > > > > with a > > > > > > > > > label object. > > > > > > > > > > > > > > > > actually it's going to be incredibly common. example: > > > > > > > > file_set on an image object... what do you think people want to > > > > > > > > do? > > > > > > > > they want to then SHOW the object or emit a signal to it or > > > > > > > > something. they want to initiate some response. > > > > > > > > for exe's and threads the object will not be magically deleted > > > > > > > > if the > > > > > > > > exe exits or thread exits. the object has to exist firstly to > > > > > > > > collect > > > > > > > > the results (i/o, exit code results etc.) - it has fd's it has > > > > > > > > to > > > > > > > > listen on etc. etc. ... > > > > > > > > > > > > > > not sure if you checked the efl_future (EFL, not EINA) version I > > > > > > > told > > > > > > > you... the object goes there for you... no need for you, the > > > > > > > promise > > > > > > > creator, to do that... > > > > > > > the promise create should only care about resolving a value or > > > > > > > rejecting it. > > > > > > > > > > > > in this case it'd be resolving the result of an action of an object > > > > > > - > > > > > > same as file_set. the object is the key thing here, not the value. > > > > > > > > > > here, since the loaded data is tied to the object... sure... but the > > > > > promise should return none, like "job" or "timeout"... you get a > > > > > notification the action completed, not the object that originated it > > > > > (ie: job is the mainloop). > > > > > > > > i agree with you here as there is no action required on the loop object > > > > once > > > > the promise is complete. because threads and exe's require action > > > > (deletion > > > > of the object otherwise you'll leak) i think it's key to pass the object > > > > here, not the exit code. :) > > > > sure. you can pass it with data... but then the user of the api no > > > > longer > > > > can pass anything else of their own as data as they used up that one > > > > value > > > > for the object which is going to need addressing as above. the exit > > > > code is > > > > going to be directly accessible from the passed object so no need to > > > > jump > > > > through hoops to get it... :) > > > > at least in THIS case i think passing exit code is worse than passing > > > > object. > > > > to boot your "i wand void pointers for threads" argument now has void > > > > ptr's > > > > for in and out values for threads... and it's likely you don't want the > > > > exit code but this value. i can't pass everything... so i have to choose > > > > something to p\[ass that is the most useful, and if i pass the object, > > > > you > > > > can get the out pointer that is the "return data" from the thread. thus > > > > i > > > > think this favours object being the value even more. > > > > > > you can pass void* as EINA\_VALUE\_TYPE_BLOB, the only thing is not much > > > can be done about it, just release (free). > > > > that's far less useful than the EO obj handle... :) this can't be done for > > the > > task class because it doesn't know about the thread superclass offering void > > ptrs. > > okay... I'm not going to convince you, so I'll stop trying.
Thanks for having trying. I haven't had the energy you have spend here. Cedric ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
