Re: [boost] Formal review: New Boost.Test Library

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-12-06 12:22:49

From: "Ullrich Koethe" <u.koethe_at_[hidden]>
> Peter Dimov wrote:
> >
> > From: "Ullrich Koethe" <u.koethe_at_[hidden]>
> > >
> > > I *strongly* disagree with your opinion. Perhaps you are right from
the
> > > standpoint of purity and beauty, but in practice floating point and
> > > collection equality are among the most frequent tests. So, until
someone
> > > implements the external module you are proposing, they *belong* to the
> > > unit test framework. One can still refactor this later.
> >
> > Why refactor later when you can refactor now?
> >
>
> If the 'float comparison module' existed, I would certainly agree to
> refactor now. But as it doesn't, a requirement 'float comparison must
> not be part of the library' would either
>
> * lead to the loss of important testing functionality, or
> * result in a substantial delay for library release.

Agreed.

[...]
> > Why do people think of boost
> > "libraries" as monolithic entities and use terms as "is a part of
> > Boost.LibFoo" and "belongs to Boost.LibBar"?
> >
>
> I'm not sure what you mean. Are you saying that the granularity implied
> by "belongs to Boost.LibBar" is too small or too large? If you mean "too
> big", then what are the parts of the testing library? If you mean "too
> small", I disagreee: I think that boost has grown to a size where clear
> boundaries between its various parts and careful dependency management
> are becoming increasingly important. So, speaking of different boost
> libraries is only natural.

I mean that the granularity is artificial, and doesn't actually mean
anything useful.

What does "float comparison must not be part of the library" mean? What is
gained by "labeling" a module as "being part of library A"? The modules
(even when they are entering boost as a bundle due to the current procedure)
must be as independent as possible. The float comparison module will still
enter boost as a result of the formal review of Boost.Test, but this doesn't
mean that it should be coupled to the other library components in such a way
so it's unusable on its own.

Clear boundaries and careful dependency management are as important _within_
a library as they're important between libraries.

--
Peter Dimov
Multi Media Ltd.