so I'm implementing a new efl.exe class (and efl.task and some others) and i
WAS going to use a future as the return for run() ... but after just writing
about 20 lines of code (get a scheduler, create a promise alloc promise data
and all the checking in between) and i then realized... it's ballooning to an
insane amount of code vs event_callback_call which is a 1 line func call when
the event happens.
let me just copy and paste the relevant lines i had sketched out (was not
final or even compiling yet):
typedef struct _Efl_Exe_Run_Data
{
Eo *obj;
} Efl_Exe_Run_Data;
static void
_efl_exe_run_cancel(void *data, const Eina_Promise *dead_ptr EINA_UNUSED)
{
Efl_Exe_Run_Data *d = data;
efl_task_end(d->obj);
}
Efl_Exe_Run_Data *d;
Eina_Promise *p;
d = calloc(1, sizeof(Efl_Exe_Run_Data));
EINA_SAFETY_ON_NULL_RETURN_VAL(d, NULL);
d->obj = obj;
p = eina_promise_new(sched, _efl_exe_run_cancel, d);
EINA_SAFETY_ON_NULL_RETURN_VAL(p, NULL);
d->promise = p;
d->run_future = efl_future_Eina_FutureXXX_then(obj, eina_future_new(p));
return d->run_future;
// XXX: no eina value for eo obj handles... :( call where exe exit handled
Eina_Value *val = eina_value_new(EINA_VALUE_TYPE_UINT64);
eina_promise_resolve(d->run_future, val);
i got to 22 lines and i wasn't even done yet (need to do some more
housekeeping)... vs 1 line for event_callback_call. i'm going with events until
futures/promises are not a crazy amount of code compared to events. this is it
with events:
efl_event_callback_call(obj, EFL_TASK_EVENT_EXIT, NULL);
my point is... futures imho are an implementation nightmare as they stand. this
needs to be simplified into a 1 liner like callback_call is i certainly do not
want to write 20+ lines of code (or that ballpark) when 1 does the job just
fine. this is the second time again that i bring up futures and usability and
whatever after there is an implementation and i'm actually using it. my gut has
been telling me and now is creaming out loud that futures/promises are a mistake
for efl.
we can spend all day long talking about how beautiful futures are in javascript
or wherever... if they are a nightmare to implement within efl like above... i
see them as a dead end. events won't make bindings that much worse, but they
will make implementing things far far far more sane. looking around at the
future code implementations ... they all are insanely wordy and long winded...
of course if someone produces a "1 liner" equivalent for futures/promises...
then i guess that's ok, but it needs to be this to be sane to keep using. so
make them simple... or abandon them. :( that's my take.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com
------------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
