[boost] Re: Re: FSM Review

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-03-13 01:19:44

> > > 2. Nothing prevent usage of the library. It's accessible. And in
> > > this particular case I noticed several support request in users ML
>
> While I agree that this is technically true, in the commercial world the
> politics matter -- and being an 'add-in' boost library makes it difficult
to
> handle.  I also believe it limits seriously the audience that will look at
the
> library because my perception is that most boost users don't mess with the
> sandbox or CVS -- they use the releases and that's it.

I really believe we need to remedy this situation. I would love to use
BOOST_FOREACH in my work projects, but end up writing my own

> Filesystem is another evolving library
> -- it solves real problems for many current users, but it doesn't do
> everything people want.  Many of the changes are usage and user driven as
> Beman evolves the library interfaces.  Some of the eventual changes are
issues
> that were known at the time of the review.  Just as another example, I
think
> boost.threads needs a full do over, but that doesn't make it any less
useful
> for those that can make use of the library as it is and boost would be
lesser
> for it's absence.

I believe in both above examples there were no major unresolved issues
revealed during review. Fixing issues is natural part of library lifecycle
whatever big changes involved.

> Much of this library future has to do with the nature of the author. One
of my
> unstated evaluation criteria is the 'behavior' of the library author.  The
> author must understand the domain, be ready to take criticism with grace,
and
> move the work forward.  If I didn't think Andreas is willing and up to
this
> task I would have voted to reject...

It's your call. I did not follow the discussion that close.

> In fact, 98% of the time
> when I'm writing a program I could care less about the traits template
> parameter and the other failings of std::string.

Just grep in boost and see in how name places libraries adding this
parameter. And you (and I and vast majority of C++ community) never need it.

> BTW, I don't think I've
> seen a proposal that identifies and eliminates all the std::string
issues -- I
> suspect that's because it's very difficult to balance the entire design
space
> for strings in a single interface.

For some time now I think we need boost::string. I hope upcoming reviews
will cover this area (at least partially).

> Anyway, while I think there are interesting directions that can be pursued
to
> expand the contribution base via the sandbox, we would need significant
work,
> in my opinion, to pursue these.  And, in fact, perhaps we would want this
to
> be a different organization from boost to make it clear that these aren't
> reviewed boost libraries.

As usual we just need volunteers to do the job ;)

Gennadiy