From: Joel de Guzman (joel_at_[hidden])
Date: 2006-10-17 22:14:59
Ullrich Koethe wrote:
> Joel de Guzman wrote:
>> Lubomir Bourdev wrote:
>>> This is why in GIL we allow the type of the result to be specified
>>> explicitly upon invoking the operation. Promotion traits can at best be
>>> useful for a reasonable default, but even then we feel that they belong
>>> in boost::type_traits and not in an image library, as the problem
>>> generalizes beyond images.
>> I agree. I am not quite fond of monolithic libraries that do everything.
>> Promotion traits and clamping, for example, can also be useful for, say,
>> signal processing of audio, among other things.
> True. But on the other hand, one has to control the number of external
> dependencies -- if a potential user must install 5 or 10 other libraries
> first, he might quickly loose interest.
> In image processing, one wants at least libjpeg, libtiff, libpng (which in
> turn requires zlib), perhaps a fourier transform library, possibly boost,
> a linear algebra library (for warping and curve fitting), a GUI library
> (which often already comes with incompatible image import/export
> functionality) and so on -- there is certainly a trade-off between
> internal and external solutions. Of course, there are platforms where
> installation is easy, but you want to be general.
Isn't this a problem of packaging instead of monolithic vs. modular
libraries? IMO, the level of granularity of a library reflects its
design. A well factored library, as a result of extensive refactoring,
over time, results in small highly orthogonal, loosely coupled sub-
libraries. A monolithic library, on the other hand, tend to devolve
into chaos over time. Don't get me wrong. I am not referring to
VIGRA; I am not familiar with it and its design. I am just talking
in general terms. And, referring back to GIL, I see that it hits the
exact sweet spot in terms of modularity.
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk