Boost logo

Boost :

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-11-20 01:56:19

--- In boost_at_y..., "David A. Greene" <greened_at_e...> wrote:
> > For example to register an action for particular argument
> > you will need somethink like:
> > new argument( ..., do_this_action_if_present() );
> > While the same logic could be implemented like this:
> > if( argument.is_present() )
> > do_somethink();
> >
> > The second version is also more stable because you now know in
> > order events will ocure.
> Hmm...I prefer the first because things are logically separated
> (defining what the option keywords are and defining what they do).
I lost me there. I think vice versa. First version unite 2 think
while second separate argument identification and parsing from
argument processing.

> We often want to do a lot more than just know if a switch
> has been set. I can imagine situations where the meanings of
> switches changes based on what other arguments are present.
> There is an ordering issue, yes. The processing order is defined
> by which order the arguments appear on the command line. Perhaps
> not ideal but some other convention could be defined.

IMHO you will immediately find a bag of problems as soon as start
mixing 2 things in one bottle. The design should encorage users to
separate actions. Was the action performd while parsing a command
line? What to do if user put arguments in wrong order? Or framework
that smart that it will be able to handle any input? We should not
make a very smart (and very complex appropriately) components by
itself. If it possible we could try to place a hook for extentions.
And everybody could make parser as smart as thay need.



> I'm brainstorming here, not presenting the One True Way.
> -Dave

> --
> "Some little people have music in them, but Fats, he was all music,
> and you know how big he was." -- James P. Johnson

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