RE: [boost] Re: Re: Preliminary submission: command line & confi g fil e library

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-01-17 16:04:40

> Why reinvent the wheel and not reuse existing code, which is much more
> flexible (and _you_ are the one, who stresses flexibility) and better
> fits into the task to solve. 

Even with my limited knowledge of Spirit, still I do not believe I duplicate
Spirit functionality in any way. What I define are the skeletons for
different parsing logics. One could choose what parser (interpreter in my
terms) to use to do a real job.

> I like the way Valodiya solves this: a
> clear, streamlined but extensible library with a simple but powerful
> interface. 

I would appreciate your comments on both submissions. Doesn't my solution is
"clear, streamlined with a simple but powerful interface. 

> If I need cla parsing (quite simple or more elabourated - as
> in your geometry sample), I can write my own parsers and make them fit
> into the picture seemless without any headache. 

So you could with my framework.

> I do not 
> expect from the
> cla framework to do the parsing for me, 

I do. Why should I repeat string->type interpretation in every program that
use cla framework. Another reason is that IMO it's more C++ like solution to
work with typed parameters and arguments. Would I work in perl I prefer
strings. Also typed parameters allowed me to perform additional validation
on whether value could be interpreted as target type.

> it should return strings
> associated with keys (which are strings too) from different locations
> (cla, cfg file, registry etc.). That's all.

I do provide an ability to return string results of course if you prefer
that.

> 
> Just my 2c worth.
> Regards Hartmut
> 

Gennadiy.