p...@highoctane.be wrote:
On Tue, Dec 2, 2014 at 4:30 PM, Ben Coman <b...@openinworld.com <mailto:b...@openinworld.com>> wrote:p...@highoctane.be <mailto:p...@highoctane.be> wrote:On Tue, Dec 2, 2014 at 4:06 PM, Sean P. DeNigris <s...@clipperadams.com <mailto:s...@clipperadams.com> <mailto:s...@clipperadams.com <mailto:s...@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.
No, I meant.. "I had to put in some structure indeed" or is it too application specific? cheers -ben
