[CLI] - Tokenizing and Parser Creation

[John Keyes <jb...@mac.com>]

Well gang I had a thought there a while ago about how the two
parsers sucked a bit (well a lot;) because they duplicated so
much code between them.  The conclusion I came to was to
implement an abstract Parser class that does all of the common
bits and have an abstract method for flattening the args.

So then to write a new parser all you have to is write a class
that extends Parser and implements the flatten method.  So the
Posix flatten does all of the bursting etc.  The Gnu flatten just
echos the args array.

The main difference that this change would make is with regards
to parser creation.  Instead of calling the Factory, all you have to
do is to instantiate the parser class.

I thought I'd throw this out there before I do a commit so any
users of the code can voice their concerns.  I think this is again
a good change as it makes the code much easier to maintain and
there is less of it to test.

-John K


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [CLI] - Tokenizing and Parser Creation

[John Keyes <jb...@mac.com>]

I've just checked in the new parser code.  I haven't modified
the manner in which the unit tests create the parsers i.e.
through the CommandLineParserFactory.  I originally created
the Factory to allow users to plug in their own parsers, all
they have to do is make sure their class implements the
CommandLineParser interface.  The new Parser class implements
the CommandLineParser interface and if someone wants to create
their own parser they just need to extend Parser and implement
the flatten method.

There are now three parser impls, PosixParser, GnuParser and
BasicParser and their flatten methods differ as follows:

o PosixParser requires a boolean (stopAtNonOption), an Options
   instance (for bursting) and the String[] of arguments.

o GnuParser requires an Options instance (for special property
   handling) and the String[] of arguments.

o BasicParser only requires the String[], seeing that it simply
   echos it.

I'm just wondering whats the best way to handle this in general.
If I was writing a parser that didn't require the stopAtNonOption
parameter then I would wonder why its on the method signature:
   String[] flatten( Options opts, String[] args, boolean stopAtNonOption)

Is there a cleaner way to handle this does anybody know?  I would
prefer not to have three flatten methods as then it would involve the
user having to implement all three of them.  I don't think there is
a very simple way but I'd be interested to hear what people think.

Cheers,
-John K

On Friday, August 23, 2002, at 09:42 , John Keyes wrote:

> Well gang I had a thought there a while ago about how the two
> parsers sucked a bit (well a lot;) because they duplicated so
> much code between them.  The conclusion I came to was to
> implement an abstract Parser class that does all of the common
> bits and have an abstract method for flattening the args.
>
> So then to write a new parser all you have to is write a class
> that extends Parser and implements the flatten method.  So the
> Posix flatten does all of the bursting etc.  The Gnu flatten just
> echos the args array.
>
> The main difference that this change would make is with regards
> to parser creation.  Instead of calling the Factory, all you have to
> do is to instantiate the parser class.
>
> I thought I'd throw this out there before I do a commit so any
> users of the code can voice their concerns.  I think this is again
> a good change as it makes the code much easier to maintain and
> there is less of it to test.
>
> -John K
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>