Thanks for doost.program_options

[Aarti_pl]

Bill Baxter pisze:
> Just wanted to say thanks to Marcin Kuszczak for doost.program_options.
> 

You are welcome! It's always nice to hear encouraging words :-)


> Works like a charm.  Sadly I'm finding I'm running into the same problem 
> I always seem to run into with Boost libraries (one of the two problems 
> anyway) -- which is documentation.  The Boost documentation is quite 
> impressive at first glance: nicely formatted, well-organized, but on 
> closer inspection the docs are often totally incomplete.  They tend to 
> document one or two common usage patterns on the one hand and then a 
> scatter shot of library minutia on the other.  But totally missing the 
> huge middle ground.
> 

I have to agree with you - few features of program options are even not 
mentioned in documentation (e.g. specifying long and short version of 
option: "version,v" - you can find it out only from examples)

> Sorry, just had to vent after spending way too long trying to figure out 
> how to get program_options to tell me the dang name of the program.
> 
> For those interested answer is you have to use the magic, undocumented 
> option specifier of the form:
> 
>       ("progdir",value!(string),"progname",value!(string))
> 
> That is, it treats a specifier with args (string,value,string,value) 
> specially, as a name for the program directory and program basename.
> 

... this part is not necessarily Boost fault :-) In fact this syntax is 
my extension to library, as the original doesn't have such a feature. 
It's documented here: http://dsource.org/projects/doost/wiki/ProgramOptions

Not very extensive information, but something at least... :-]


> Totally not Doost's fault that Boost libraries are poorly documented, of 
> course.  Just annoying.  I don't really understand why everyone is so 
> wild about Boost.  I've yet to meet a Boost library that didn't waste 
> hours of my time just in trying to accomplish the most basic thing.
> 
> One enhancement request -- it would be nice if there were a keys() 
> method on VariablesMap.  Just this in variables_map.d is all that's needed:
> 
>     string[] keys() {
>         return m_variables_map.keys;
>     }
> 
> Maybe a values method too -- but I don't really see a good use case for 
> that.
> 
> --bb

IMHO the main problem with Boost libraries is that they are very 
difficult to extend and maintain. I would say that where possibilities 
are already finishing in Boost(due to overwhelming complexity) they are 
just beginning in D...

And the cake for finish ;-)

I am currently working on completely refactored version of program 
options. Planned features include:

- Tango compatibility (I am slowly creeping to Tango camp too :-) )

- possibility to store options in backends (I will create Database 
backend (using DDBI) and extend config files backend / environment 
variables backend to enable storing variables)

- custom value types (I couldn't translate it from Boost when making 
original translation)

- changing implementation style to be more D-ish

- Extended documentation and tests

Unfortunately it's slow process as I can not give much of my time for 
this purpose... Anyway at the point of release I will need people to 
thoroughly review API and design. And you are first candidate to be 
reviewer ;-)

Best Regards
Marcin Kuszczak
(aarti_pl)