Re: [boost] Extending Boost.Program_options

From: Tom Bachmann (e_mc_h2_at_[hidden])
Date: 2007-03-20 08:05:30

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> > The easiest fix would be to add a public interface to change the value
>> > of an option in a variables map, by making op[] return a non-const
>> > reference. I'm not sure if code should be added to call semantic ->
>> > notify automically.
> 
> Yep, I guess we need non-const-returning[] for sure. We probably should
> have variable_value overload operator=, and call semantic->notify.

Yes, this sounds cleanest.

> Do
> you think disallowing assignements that change value type is OK? Say,
> if you try to assign int to value of type double, you get exception.
> 

This sounds sensible to me.

>> > 2 find out the type of an option
>> > 
>> > This is not strictly necessary, but I'd be nice to e.g show a checkbox
>> > for bool options, a spin button for numeric options, and an entry field
>> > for other options. I currently infer the type by querying the Boost.Any
>> > that holds the option, potentially after applying the default value.
>> > This is not foolproof, however, because it fails for options that have
>> > no default value and that have not been set before.
> 
> Technically speaking, the value_semantic base class does not require an
> option to have any type at all. At the same time, in 100% of known cases
> the type for an option is known. Perhaps I can either add 'type' method
> to value_semantics that returns type_info* and may return NULL, or just
> make it return type_info& and demand that all options have a fixed type.
> Will either of those approaches work for you?
> 

Either will work.

>> > 3 convert from an option value to some screen representation
> [...]
> One another approach is make variable_value record original tokens it
> was constructed from. This correlates with your point (1) above --
> perhaphs after UI was changed, value_semantics->parse should be called
> to get new boost::any and the parsed tokens should be stored in variable_value.
> 

Again, this sounds cleaner than my proposal.

>> > 4 find out what options in a po::options_description are members of what
>> >   option groups
>> > 
>> > This is necessary to group the options in multiple tabs. Again, there
>> > are only private interfaces to access the information.
> 
> The problem here is that when you add one options_description to 
> another options description, the original object is not retained, so
> it's not simple to have "parent pointer". It might be possible to 
> have "parent group name" field in an option. Would that be too cumbersome
> to construct UI hierarchy grouping options by string parent name?
>  

Putting the parent string into every option sounds unnecessarily
complicated too me (from a user perspective). What about making
options_description manage map of views in the main options vector, that
is, something like map<parent_string,vector<option*> >. With an adequate
public interface, my problem would be solvable in a strightforward way.

With the interface changes described, a clean options window
implementation seems to be possible.
- --
- -ness-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF/84JvD/ijq9JWhsRAqmgAJ9i28pXZH/iO7/73xCsjOB2b9MJtACeMNkp
FYAYuTktzPcevz76exgZFWA=
=F50V
-----END PGP SIGNATURE-----