Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-17 05:12:08

I'm sorry for extremely delayed reply -- I've missed the message I'm
responding to.

David A. Greene wrote:
> Vladimir Prus wrote:
> > Let's try to find what is needed actually. A while ago to configure
> > subcomponents I was actively using very simply approach --
> > hierarchical naming, e.g. options that look like:
> > --scheduler.ordering=sms
> > It was sufficient for my purposes. It is ok for you?
> Yes, that's pretty much what I have used as well.


> > Dynamic loading is a problem (at least for me :-) )
> > because it will erase the distinction between
> > syntantic and semantic phases.
> I understand the "academic" reasons for this desire, but I
> wonder if it is too restrictive in practice. My primary
> design goal for an argument parser would be easy to use.

Another attactive aspect of separation is that it would allow to write an
*extremely* lightweight syntax parser, that will be usable separately. I
guess someone will want to use only it, without any semantic features like

> > 1. Programmer defines a "loose" syntax: e.g. where any options
> > starting with "--scheduler." are allowed.
> I don't quite follow you here. To make it more concrete,
> are you saying the "loose" syntax should be something like
> "--plugin<name>=<plugin_options>" (don't worry about the
> syntax now, just the idea) where there's a "well known"
> "--plugin" option that can be used to specify a plugin to
> load and options to pass to it? This is essentially
> what we have done. Ultimately the programmer defines
> what the "well known" interfaces are (--scheduler could
> be a special kind of plugin, for example).

Looks like we're of the same mind here.

> > 2. Command line is parsed.
> > 3. Options are examined, and the set of required plugins is computed.
> > 4. New options description is computed, this time asking loaded
> plugins about
> > exact syntax.
> > 5. Syntactic and semantic parsing is performed.
> This sounds reasonable to me. The way our system works,
> when the "--plugin" option is parsed, the plugin is immedately
> loaded and a method is invoked for the plugin to add
> its options to the tree. The parser then traverses the rest
> of the --plugin option string (i.e. the arguments for the
> plugin). Since the plugin added its arguments to the
> tree this should succeed.
> It's essentially the system you describe except that, as
> you note, the syntax and semantics are mixed. I am starting
> to like your separation idea. The academic in me is
> starting to show. :)

Good. Probably, we can refine the design for mutual benefit :-)

> That said, I still don't like this sort of syntax:
> parseOptions(argc, argv);
> if (wasPassed(options, "some-option-name")) {
> doSomeOptionNameAction();
> }

Sorry, but it is *not* my syntax.

> I think it is too verbose and error-prone.


> I still much
> prefer this:
> options.register("some-option-name", "some-option-help",
> someOptionSemanticActionFunctor());
> options.parse(argc, argv);
> It keeps everything more "together." The semantics
> invocation can still be delayed with the model.

Well... except for some details, this is the same method of describing
options that I use!

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at