-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
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. |
I.e., not what I just had to do in the web-playground app:
|
An additional issue directly related to this, which I just hit in web-playground. I'd forgotten that Rather than do that I'll probably yak shave this bug. |
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):
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 hasinit-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.The text was updated successfully, but these errors were encountered: