[Dune] ConfigParser

[Carsten Gräser]

In my opinion multiple values per key would be a little complicated,
since we would then need a consistent interface to access them.

Your suggenstions for the comand line options are definitly good,
but I'd like to have them split from the data structure. Furthermore
I'm not sure if we should implement all of this ourselfs.
The functionality you describe is essentially what gnu getopt provides.
A nice C++ version for this functionality is provided by boost::program_options.

Similarly the ParameterTree is essentially boost::PropertyTree.
IMHO having a simple version of this in dune is nice. But before
reimplementing every detail we should meditate a few minutes on the
following statement from the boost::PropertyTree web page:

"Many software projects develop a similar tool at some point of their lifetime, and property tree
originated the same way. We hope the library can save many from reinventing the wheel. "

Best regard

Carsten




Am 07.06.2010 14:45, schrieb Jö Fahlke:
> Am Mon,  7. Jun 2010, 13:58:44 +0200 schrieb sander at dune-project.org:
>> The usage and implementation is the one from the ConfigParser class.
>> We may want to discuss whether there are better designs/implementations
>> for this.
> 
> Well, here are some features I would like to see in a future version of
> ConfigParser/ParameterTree:
> 
>  * Ability to delete values/keys/subtrees.
> 
>  * Multiple values per key.
> 
>  * A way to combine two ParameterTrees.  This is tricky in combination with
>    multiple values per key -- we need a way to specify whether a particular
>    key add its values to the ones already present or overwrites them.
> 
>  * Command line parser needs some improvements:
> 
>    - Currently something like "-foo 1 2" results in the key "foo" having the
>      value "2".  Instead the key "foo" should have value "1" and the "2"
>      should be left alone.
> 
>    - "-option=value" syntax.
> 
>    - Remove the recognized options from the command line.  This should leave
>      other arguments which the program may then treat as files to process or
>      whatever it likes.
> 
>    - Boolean options instead of "-help 1" just say "-help".  Or, even better,
>      with the "-option=value" syntax allow these: "-option" or "-option=yes"
>      to set a boolean value true and "-no-option" or "-option=no" to set a
>      boolean value false.
> 
>  * Some of the stuff above can be addresse by having a scheme for the
>    supported options: Some data structure which lists for each supported
>    option whether it is multi-valued, boolean, integer.
> 
>    - The scheme may also include a help text and possibly a default value.
> 
>    - The scheme may group options such that they are overwritten together when
>      combining two parameter trees.  For instance, if ParameterTree1 contains
>      values for "epsilon" and "mu" and ParameterTree2 contains values for
>      "epsilon" and "c" and the keys "epsilon", "mu", and "c" form a group,
>      then the resulting ParameterTree should not contain a key "mu".
> 
> Most of these ideas a rather vague, some are a lot of work and may not be
> feasible, but I guess it's a starting point for a discussion.
> 
> Thanks,
> Jö.
> 
> 
> 
> 
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune


-- 
----------------------------------------------------------------------
Carsten Gräser           | phone: +49-30 / 838-75349
Freie Universität Berlin | fax  : +49-30 / 838-54977
Institut für Mathematik  | email: graeser at math.fu-berlin.de
Arnimallee 6             |
14195 Berlin, Germany    | URL  : http://page.mi.fu-berlin.de/graeser
----------------------------------------------------------------------