On Tue, Dec 2, 2014 at 4:30 PM, Ben Coman <btc@openinworld.com> wrote:
phil@highoctane.be wrote:
On Tue, Dec 2, 2014 at 4:06 PM, Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>> wrote:
EstebanLM wrote > is cool. > I would like to explore the possibility to replace our command line parser > with getopt. You know⦠is more compatible at the end :)
I find the implementation of our command line handlers very confusing. It seems like it grew organically from a smaller idea and the design got out of control. There are many assumptions that can make it hard to extend, especially to combine multiple options, as Ben and I discovered when implementing the "don't run startup scripts" handler. It would be nice to revisit starting from a behavioral specification.
Well, what makes you say that? The core CommandLineHandler itself is pretty generic and can do a lot of things.
Then, yeah, what is under is quite varied. But that's to be expected when trying out "new tech".
I've been making one of my own here for a given project with about 20-30 commands and I had to put in some structure indeed.
Is that part available somewhere that can be reviewed ?
You mean? CommandLineHandler and CommandLineArguments is in the base image. Phil
cheers -ben