On Tue, Dec 2, 2014 at 4:55 PM, Ben Coman <b...@openinworld.com> wrote:
> 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? > Oh, that, yeah it is full of customer code, so no way. But I like to use protocols to organise things and do lookups using that. So I do not have complicated tables to maintain not pragmas to put around. so: (activate) for the main activate along with some self hasOption:#debug ifTrue: [ self beDebug ] ifFalse: [self beNormal] option to trigger console logging in order to see what's going on in the process. I've put a logCall here and there with self log: thisContext receiver so I can see what's going on. This thing is triggered by the beDebug. Some NonInteractiveTranscript install as well. that looks in the following prototcol (activate commands) activateAbc activateDef And the class side does its thing with isResponsibleFor: activateAbc will ask for Abc in the (actions) protocol Abc will call GetOpt to read the parms of the command. The some logic and exits. The self exit things are streamlined (more of a pattern than a mechanism). ... Once this was done, I added a ton of commands in no time and they all look like the same "way of doing things". HTH Phil > cheers -ben > > > >
