From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-07-03 12:52:03
On Wed, Jul 3, 2019 at 3:41 PM Andrey Semashev via Boost <
> On 7/3/19 3:36 PM, Emil Dotchevski via Boost wrote:
> > On Tue, Jul 2, 2019 at 7:19 PM Nevin Liber via Boost <
> > wrote:
> >> On Thu, Jun 27, 2019 at 7:41 PM Robert Ramey via Boost <
> >> boost_at_[hidden]> wrote:
> >>> Here you've exactly hit on the motivation for mother of all variants.
> >>> It should be clear by now that as library developers we cannot
> >>> anticipate the needs and desires of our potential users and at the
> >>> time document the rational and restrictions of the particular variant
> >>> question.
> >> That is true about every type in existence. Variant is not special in
> > this
> >> regard.
> >> And if "we cannot correctly anticipate the needs and desires of our
> >> potential users", policies also "cannot correctly
> >> anticipate the needs and desires of our potential users" either.
> >> do not solve this problem.
> > +1
> > Worse, policy-based designs are the result of the expert in the problem
> > domain (the library author), unable to make up his mind about the
> > design, pushing that responsibility to people who are less knowledgeable
> > (the library users).
> I wouldn't put it that far. A policy can be useful when there are
> legitimate use cases for multiple behaviors in some aspect for the
> otherwise same component.
A policy is an example of a customization point. Obviously, many
customization points are legit yet, practically speaking, policy-based
designs tend to be like I described them.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk