Page MenuHomePhabricator

efl.task
Open, TODOPublic

Description

| |class Efl.Task
| |├ (P) command
| |├ (P) arg_count
| |├ (P) arg_value
| |├ (P) env
| |├ (P) priority
| |├ (P) exit_code
| |├ (P) flags
| |├ (M) arg_append
| |├ (M) arg_reset
| |├ (M) env_reset
| |├ (M) run
| |├ (M) end
zmike created this task.Wed, Jan 9, 10:19 AM
zmike triaged this task as TODO priority.
zmike moved this task from Backlog to Evaluating on the efl: api board.Thu, Jan 17, 11:09 AM

I think that arg_count, arg_append,arg_value and arg_reset are not a nice API for any binding as it look very foreign. Better API would be either to just have an Eina_Array or Eina_List based API. This would allow most binding to do something like :

app.args = [ 'titi', 'toto', 'tata' ];
app.args.foreach(function (arg) { console.log(arg); });

env{ set; get } and friends has the same inherent problem. Also general documentation is really unclear to me.

Flags needs documentation to be properly reviewed.

I also do not know if I can call "Run" multiple time. Documentation could be improved.

I agree on everything @cedric just said.

bu5hm4n added a comment.EditedSat, Jan 19, 3:31 AM

@cedric D7510 / D7516 is working on this.

The only difference here is that we have two fill operations, one for a array, one for a string. Reason for this is that sometimes it is usefull to have a string, sometimes its usefull to have an array.

I also moved things out of efl_task for the simple reason that it does not really below there IMO, but rather belong to a higher level object. String-based Arguments are nothing for a general purpose task abstraction, rather something for a application.

We should think about a namespace ?