New idiom for scala-like implicits while trying to make mixin expressions.

[aliak]

On Saturday, 14 March 2020 at 19:00:52 UTC, Adam D. Ruppe wrote:
> On Saturday, 14 March 2020 at 16:42:11 UTC, aliak wrote:
>> Why does it scare you?
>
> It just indicates to me that there might be a better way.

I think I may have missed what scares you. Was it that mixins 
cause pollution or that I thought not causing pollution was an 
advantage or was it that I thought of mixins? (or something else?)

>
>>   * Having to always mixin something into your struct if you 
>> can get it automated seems unnecessary. Sure you can do it, 
>> but why when it can be avoided?
>
> You're manually writing the function call, which is unnecessary 
> too, so the question is just where you want to write it. It is

In regards to the previous suggestion from the last post, you're 
mixing in the parse function, then calling it (2 steps). Whereas 
the alternative was just calling it. This next suggestion with 
reflection through is indeed "stepless", but a lot more setup 
work and is indeed another way to go.

Now the difference becomes whether you want the options spread 
out all over a struct or contained at the call-site of parse. My 
first thought is to have them contained because these structs can 
get pretty big depending on the number of sub-commands.

> possible to do this kind of thing with only one explicit 
> "parse" or "runCommand" or whatever call for the entire 
> program, with the rest being done automatically through 
> reflection.
>
> ---
> @help("help text")
> @command("cmd1")
> struct Command {
>   bool option; // options for this command
>   string whatever;
>
>   int opCall() {
>         // execute implementation
>         return 0;
>   }
>
>   @help("more help text")
>   @command("cmd2")
>   struct InnerCommand {
>       int opCall() {
>           // do whatever
>       }
>   }
> }
>
> int main(string[] args) {
>    // or you could list it manually or whatever
>    return runCommand!(getMembersByUda!(mixin(__MODULE__), 
> command))(args);
> }
> ---
>
> So then all your implementations are in one function, your 
> options are simple members, subcommands are nested (or can be 
> external and aliased in there btw), no more writing `parse` 
> separately at all - no mixin, no needing to know context.
>
> And you can also call the commands from code pretty easily.
>
> Command cmd;
> cmd.option = true;
> cmd();
>
> or run an individual one with strings
>
> runCommand!Command(["--option"]);
>
> and so on. Moving all that logic outside makes the code the 
> most succinct.