On Sat, 16 Feb 2019 01:09:05 + Cedric Bail said:
> On Friday, February 15, 2019 3:58 AM, Carsten Haitzler
> wrote:
> > On Fri, 15 Feb 2019 12:29:21 +0100 Marcel Hollerbach m...@bu5hm4n.de said:
> > > On 2/15/19 11:27 AM, Carsten Haitzler (The Rasterman) wrote:
> > > > On Thu, 14 Feb 2019 19:05:56 +0100 Marcel Hollerbach m...@bu5hm4n.de
> > > > said:
> > > > > On 2/14/19 11:10 AM, Carsten Haitzler (The Rasterman) wrote:
> > > > > > On Wed, 13 Feb 2019 17:40:33 +0100 Marcel Hollerbach m...@bu5hm4n.de
> > > > > > said:
> > > > > > > On 2/13/19 11:00 AM, Carsten Haitzler (The Rasterman) wrote:
> > > > > > > > On Tue, 12 Feb 2019 22:05:06 +0100 Marcel Hollerbach
> > > > > > > > m...@bu5hm4n.de said:
> > > > > > > No, but honestly, i am not trying to make life in C harder.
> > > > > > > Moving the POV from the amount of
> > > > > > > chars per API call, into something like usage range of our
> > > > > > > abstraction shows you that efl_task is now usable in a wider
> > > > > > > range, and even efl_env is more powerfull than before. Further
> > > > > > > more, compare the bindings code before and after the patches, you
> > > > > > > will see that the code integrates much nicer now, while its a
> > > > > > > little more (expressive) code in C.
> > > > > >
>
> > > > > > i don't believe it is nicer. it's an extra object to create and
> > > > > > hook in. it's less obvious to the developer in non-c langs - as
> > > > > > opposed to just setting env on an obj u have u have to know to
> > > > > > create another then configure it then set it... etc. or similar. in
> > > > > > every case it is probably more code for the developer. this
> > > > > > direction is really worrying. We have a corepoint where we disagree
> > > > > > here. I would say that an principle like
> > > > > > "Composition over inheritance" or SOLID or GRASP do have a reason
> > > > > > to exist. And what they pretty much advertice is that seperation of
> > > > > > objects also seperates
> > > > > > your concerns, which makes testing etc. etc. easier.
> > > >
>
> > > > that's subjective. there is an objective measure that there is more
> > > > code to write in c and more moving parts to get to know and to then get
> > > > wrong. it is more code. even if the args array and content is consumed
> > > > so caller doesn't have to clean up anything (where your design requires
> > > > partial cleanup by the caller) it's more. i converted the exe and
> > > > threads examples that used args (wiki still has the old code) -
> > > > https://phab.enlightenment.org/w/efl-loops-threads/ . exe needed an
> > > > extra 5 lines of code (65->70), the threads example needed 16 more
> > > > lines of code (177->193). considering most of the code was other stuff
> > > > not related to args or env... compare:
> > > > Eo *obj = efl_add(EFL_EXE_CLASS, app,
> > > > efl_task_arg_append(efl_added, "./test.sh"),
> > > > efl_task_env_set(efl_added, "BLAH", "blahvalue"),
> > > > efl_task_flags_set(efl_added,
> > > > EFL_TASK_FLAGS_USE_STDOUT | EFL_TASK_FLAGS_USE_STDIN),
> > > > efl_event_callback_add(efl_added, EFL_IO_READER_EVENT_CAN_READ_CHANGED,
> > > > _read_change, NULL), eina_future_then(efl_task_run(efl_added),
> > > > _task_exit, efl_added) );
> > > > vs
> > > > Eina_Array *args = eina_array_new(1);
> > > > eina_array_push(args, eina_stringshare_add("./test.sh"));
> > > > Eo *env = efl_duplicate(efl_env_self());
> > > > efl_core_env_set(env, "BLAH", "blahvalue");
> > > > Eo *obj = efl_add(EFL_EXE_CLASS, app,
> > > > efl_core_command_line_command_array_set(efl_added,
> > > > args), efl_exe_env_set(efl_added, env),
> > > > efl_task_flags_set(efl_added,
> > > > EFL_TASK_FLAGS_USE_STDOUT | EFL_TASK_FLAGS_USE_STDIN),
> > > > efl_event_callback_add(efl_added, EFL_IO_READER_EVENT_CAN_READ_CHANGED,
> > > > _read_change, NULL), eina_future_then(efl_task_run(efl_added),
> > > > _task_exit, efl_added) ); efl_unref(env);
> > >
>
> > > Wondefull lineout to use a api how you should not. thx for that!
> > > The code should rather be:
> > >
>
> > > Eo *env = efl_duplicate(efl_env_self());
> > > efl_core_env_set(env, "BLAH", "blahvalue");
> > > Eo *obj = efl_add(EFL_EXE_CLASS, app,
> > >
>
> > >
>
> > > efl_core_command_line_command_string_set(efl_added, "./test.sh"),
> > > efl_exe_env_set(efl_added, env),
> > > efl_task_flags_set(efl_added,
> > > EFL_TASK_FLAGS_USE_STDOUT | EFL_TASK_FLAGS_USE_STDIN),
> > > efl_event_callback_add(efl_added,
> > > EFL_IO_READER_EVENT_CAN_READ_CHANGED, _read_change, NULL),
> > > eina_future_then(efl_task_run(efl_added),
> > > _task_exit, efl_added)
> > > );
> > > efl_unref(env);
> > > Further more, if you start this exe a few times, please save the env
> > > object somewhere, so you don't repeat the work.
> >
>
> > the original code sets args separately - read it. the threads test sets 2
> > arguments separately so you don't have to go escaping the command string
> > before setting it. it's an illustration that where code is
