Re: [boost] Re: Any interest for a parser class?

From: David B. Held (dheld_at_[hidden])
Date: 2002-01-18 15:36:42

-----Original Message-----
From: rogeeff <rogeeff_at_[hidden]>
To: boost_at_[hidden] <boost_at_[hidden]>
Date: Friday, January 18, 2002 12:43 PM
Subject: [boost] Re: Any interest for a parser class?

>Generic parser should not rely on ANY parser. It should 
>not even need not know about existance such beast like 
>complex parser.

I think I understand what you are suggesting now.  You are saying
that a CLA library should not be responsible for actually *parsing*
the options, just storing them.  I don't see a general concensus on
this view.  Even Bill Kempf's implementation parses the input
"internally".  I assume Vladimir Prus' implementation does so as 
well.

>It can handle fixed range of argument iddentification/value 
>parsing rules (but wide enough to cover most of CLA parsing 
>needs) and provide an abstract interface for user to add custom 
>argument.

If I understand you correctly, you are saying that the CLA library
would provide a minimal set of parsing structures to handle most 
common situations, but they would be external to the CLA
framework itself.  To me, that seems odd.

>This argument encapsulate and implement somehow custon 
>parsing logic, that include custom identification and custom 
>value parse. That's it. And let everybody decide whatever they 
>want to use.

So for someone to imlement custom option formats, they have
to provide their own parser.  Sure, that's very flexible; but how
powerful is it?  I wouldn't be highly motivated to use such a 'lazy'
CLA library myself.

And ultimately, you are suggesting that the CLA library ship
with several hand-rolled parsers.  Well, as long as that remains
a fixed set, that's fine.  But as people have need for more
complex option formats, the value of a non-parsing CLA
library will decrease significantly.  Whereas, the set of
included parsers themselves could have been the products of
a parser-generator; in which case you already have an engine
for creating new parsers for new formats.

We went from std::auto_ptr to boost::smart_ptr.  Now we're
talking about Loki::SmartPtr because we aren't satisfied just
handling the minimal set of cases.  Isn't it taking a step back
to offer such a weak CLA library?  I mean, you said yourself
that hand-rolled CLA parsers are a dime a dozen, and now
you just want to standardize one.  It seems to me that boost
is not about libraries that just anyone can write.  It's about
powerful libraries designed carefully and thoughtfully by
fairly intelligent people, that the rest of us have the benefit of
using.  Since a more powerful parsing engine is already
available to us, why not create a more powerful CLA framework
that *can't* necessarily be hand-rolled in 2 hours, that
covers a much broader range of possibilities, in the way
that smart_ptr covers more possibilities than auto_ptr?
I know someone that swears by auto_ptr, and never even
considered using boost::smart_ptr, insisting that it's
unnecessary for most situations, and so there's no point
in using it or learning a "more complicated smart pointer".
On the other hand, I don't know anyone who's actually used
boost::smart_ptr and failed to recognize the value it adds
to their code, even though they may have had to read a
little more documentation to use it properly.  I can't help but
feel that you are that person saying: "I really like std::auto_ptr.
It's good enough for me, so it's good enough for everyone."

Dave