Re: [boost] CLA Library (was: Any interest for a parser class?)

From: David B. Held (dheld_at_[hidden])
Date: 2002-01-18 17:07:57

-----Original Message-----
From: Douglas Gregor <gregod_at_[hidden]>
To: boost_at_[hidden] <boost_at_[hidden]>
Date: Friday, January 18, 2002 03:45 PM
Subject: Re: [boost] Re: Any interest for a parser class?

>On Friday 18 January 2002 04:19 pm, you wrote:
>[...]
>Sorry, I'll try again. Let's assume that CLA is a command-line parser
class.
>CLA will contain the ability to parse several types of options (e.g., -foo,
>--bar=value). However, we know that CLA can't always do everything that the
>user needs, so CLA needs to be extensible to be able to meet the needs of
>these users.
>
>I'm suggesting that for this extensibility, the CLA class allow the user to
>give it a function object that is responsible for parsing part of the
command
>line. The function object would then be a Parser that can parser some or
all
>of the remaining command line, and tell the CLA class what it did. This
way,
>the CLA class is extensible by any option syntax the user can come up with,
>as long as they can write a parser to handle it.
>[...]

This sounds like what Gennadiy is suggesting.  I guess that's at
least two votes for "external custom parsing".  Still, it seems a
shame to burden the user with parsing responsibilities just
because the framework chose to use hardwired parsers.  I think
I feel this way because it seems likely that the custom parsing
object will almost certainly have to duplicate many of the things
the CLA framework already does internally, or the framework
will have to expose a lot of interface so that an external parser
could take advantage of the internal facilities.  Whereas, if the
framework itself provided custom parsing facilities, everything
is "in-house", you can maintain a minimal user interface, and
there is no code duplication between the user and the library.

Dave