Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too much boilerplate #16

Open
cgay opened this issue Jan 9, 2020 · 3 comments
Open

Too much boilerplate #16

cgay opened this issue Jan 9, 2020 · 3 comments

Comments

@cgay
Copy link
Member

cgay commented Jan 9, 2020

If I'm writing a command-line tool that takes one command-line option, I shouldn't have to add 10 lines of boilerplate code on top of my flag definition. I should just be able to say something like this (not trying to use the existing type names below):

define flag $build-directory-flag
  = make(<flag>, name: "build-directory", type: <string>, required?: #t);

define function main ()
  init-dylan-application(); // Do standard stuff like parsing the command line
  ensure-directories-exist($build-directory-flag.flag-value);
  ...
end;

It shouldn't be necessary to make a command line parser object, or add the options to it or catch errors to display help and usage.

Maybe the command-line-parser library can just have a single global parser object (since that should work for just about everything except testing), register flags for it in the make method, and provide a macro to do the help/usage handling.

Maybe we need an application library that has init-dylan-application as in the code snippet above. This could take keyword args to enable/disable various standard things like logging, command-line parsing, etc.

@cgay
Copy link
Member Author

cgay commented Jan 9, 2020

Forgot to mention one of the worst aspects of the current design is having to ask the parser object about a flag by passing the flag name (a string) to the parser. It's easy to have that string get out of sync with the flag definition so almost requires having a separate constant for the flag name. Ick.

@cgay
Copy link
Member Author

cgay commented Jan 9, 2020

I.e., not what I just had to do in the web-playground app:

define constant $command-line-parser
  = make(<command-line-parser>, min-positional-options: 0);

define constant $prebuild-directory
  = make(<parameter-option>,
         names: #("prebuild-directory"),
         help: "Pathname of the _build directory to copy to make initial builds fast."
           " If not supplied the initial build will take minutes.");

add-option($command-line-parser, $prebuild-directory);

define function main ()
  block ()
    parse-command-line($command-line-parser, application-arguments(),
                       description: "Dylan web playground");
  exception (ex :: <help-requested>)
    exit-application(0);
  exception (ex :: <usage-error>)
    exit-application(2);
  end;
  let server = make(<http-server>);
  add-resource(server, "/play", $playground-page);
  http-server-main(server: server);
end function;

@cgay
Copy link
Member Author

cgay commented Jan 9, 2020

An additional issue directly related to this, which I just hit in web-playground. I'd forgotten that http-server-main() in the above code already parses the command line. With the current design it's impossible for me to just add another flag to the command line and use it and still call http-server-main() to parse the arguments. I either have to reimplement the HTTP server flags I need and pass them to make(<http-server>) or come up with some other work-around.

Rather than do that I'll probably yak shave this bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant