Re: [boost] Policy-based designs considered harmful?

From: Lee Brown (lee_at_[hidden])
Date: 2002-01-24 14:34:43

On Tuesday 22 January 2002 10:45, you wrote:
> Point taken. I guess the discussion becomes a pretty heavy argument in
> favor of orthogonality. Frankly, I haven't realized that before, although
> instinctively 'orthogonal' is 'good' :o).

I am having trouble with this term "orthogonal."  I understand the geometric 
meaning of orthogonal "v dot v = 0" , but what are the criteria for 
ortthogonality of policies?  People will say "unrelated", but what does
"unrelated" mean?   Classes are a unit, which to some degree, implies that
all parts are interrelated to eachother. 

Policies are to be used in many classes.   Policies may take classes as 
templates.  It is conceivable and realistic to believe that
ceratain sequences of instructions will put the contained or containing 
systems in a undesirable state.  A policy after all, merely provides an
interface: it says nothing about the underlying system.  Many systems have 
the same interface, but qualitatively differenet behavior under the same 
sequence of instructions ( environmental input). 

For example, the mutex policy. For recursive mutexes, calling lock repeatedly
is fine. For nonrecursive, it is undefined.

template <class mutexpolicy>
void doit_func()
{
        mutexpolicy r;
        r.lock(); 
        r.lock() ;  
}

typedef doit_func<recursive_mutex> recur; /// OK
typedef doit_func<fast_mutex> fast;  // BAD

Anyway, this is just a thought.  It may not a particularly
good one at that.

Lee

> Policies are nothing but glorified interfaces in conjunction with the
> Strategy design pattern. They are more flexible because they allow exposing
> types, not only binary signatures, and more efficient because they combine
> at compile time. They lose in the binary standards aspect.
>
> Anyway, you can imagine a class that stores and uses various interfaces
> that provide functionality. The class is not aware on the way that that
> functionality is implemented. How do you test such a class using
> strategies? (I'm not an expert, but I suspect that the separation between
> those interfaces eases the job considerably.) Same testing methods should
> apply to compile-time combinations with policies.
>
>
> Andrei
>
> ---------------------------------
> Check out THE C++ Seminar:  3 Days with 5 Experts
> http://www.gotw.ca/cpp_seminar/
>
>
> Info: http://www.boost.org  Send unsubscribe requests to:
> <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/