Re: [boost] Loki SmartPtr study: Policy orthogonality issues

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-05 14:26:18

At 03:58 PM 1/4/2002, David Abrahams wrote:

 >I have suggested several times that we look at the Policy Adaptor pattern
 >used by the Iterator Adaptors Library. It certainly makes the problem of
 >policy interaction go away, since all of the policies are collected in 
one
 >place... but there have been no replies, and I am wondering why. Is it 
seen
 >as inappropriate for smart pointers? Are people having trouble
 >understanding the suggestion?

I am.  Every time you mentioned it (once in person, several other times in 
postings), I went back and read portions of the paper.  In particular, the 
section below.  How does it a apply to smart pointers?  Smart pointers 
don't seem to have nice neat models of concepts like InputIterator, 
ForwardIterator, BidirectionalIterator, or RandomAccessIterator.  Or if 
they did, there would be hundreds of them. I think the iterator example is 
confusing me.  With smart pointers the starting point (in my mind) is a 
feature model.  That translates nicely (as done by Andrei) into a set of 
policies, which are for the most part orthongonal.  Each of the policies 
has two or more default implementations, corresponding to the common 
feature variations for that Policy.  I don't understand how to (usefully) 
mash the policies together into a single policy. I'm basically lost.

--- start portion of the paper ---

The Policy Adaptor Design Pattern

The Iterator Adaptor Library illustrates how a generalized Model (iterator 
adaptor) of a concept family (iterators) combined with default policy 
delegation allows users to easily build new Models and behavioral adaptors 
for existing Models. We can capture this strategy in the Policy Adaptor 
design pattern: (see footnote below)

1. Identify the core elements of the public interface of the concept family 
to be modeled. In our case, the Adaptor will model one of the iterator 
concepts: InputIterator, ForwardIterator, BidirectionalIterator, or 
RandomAccessIterator (this depends on the base iterator type and the 
parameters of the Adaptor).

2. Encapsulate core elements of the concept family in a Policies concept.

3. Write a default policies class which delegates behavior to the public 
interface of the Adaptor's concept. This is the mechanism that supplies 
default adaptation behavior.

4. Build an Adaptor class template parameterized on Policies. The Adaptor 
should be a generalized model of the Adaptor Concept, providing the public 
interface, but delegating functionality to the policies class.

5. Store a member of the Policies parameter in the Adaptor template so that 
users can maintain additional state while taking advantage of default 
behavior delegation. We believe this design pattern is a powerful new tool 
for modeling any concept which varies along several axes and contains 
significant redundancy.

footnote: This is not quite the same as the Policy Class pattern which has 
been discussed previously in the literature [Modern C++ Design]. The 
construction of an adaptor which can easily transform existing Models into 
new ones is the key difference

--- end portion of the paper ---