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

Adam D. Ruppe destructionator at gmail.com
Sat Mar 14 19:00:52 UTC 2020


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.

>   * 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 
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.


More information about the Digitalmars-d mailing list