Re: [boost] Re: communication between policies (in Loki::SmartPtr)

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-24 11:44:05

At 04:41 PM 1/22/2002, Andrei Alexandrescu wrote:

 >> But when a framework class has forwarding functions whose only job is 
to
 >> facilitate communication between policies, the polices aren't "truly
 >> orthogonal" in my mind.
 >
 >I disagree. If the framework is the only facilitator for communication, 
you
 >have a unique point of review and maintenance for the communication. If
                                    ^^^^^^^^^^^
If the framework is in a library I don't control (such as the standard 
library), I can't do maintenance on it.

 >policies can communicate freely, it's all much more messier.

Policy requirements must to be fully specified, regardless of whether they 
communicate indirectly through the framework or directly.  So the 
"messiness" for policies is the same either way.  But the framework is 
messier if the policy communication is indirect through it.

 >Functions that provide plumbing between otherwise independent components
 >that live in total ignorance of each other are common in all designs, and 
a
 >sign of good quality in many.

That sounds good.  In fact, if the components are in separate layers it is 
often an absolute requirement.

But when the components are policies for the same object, it limits use to 
communications foreseen and approved the framework designer.  Sort of a 
central planning approach.  That may be good or bad, depending on the 
application.

For smart pointers, if someone takes a very focused view of what a 
"pointer" is, to the point of even saying it doesn't cover "pointer to 
array with natural and safe array operations", then mandating all policy 
intercommunication through the framework is a good thing.

But others who want a more general resource management tool, where the 
resource may not be a pointer or handle or anything remotely like a 
pointer, will go off an do a framework which allows direct inter-policy 
communication.  And this framework will be able to do everything the 
restricted framework can do plus a lot more.  Some will prefer that, others 
will regard it with horror.  I guess it comes down to personal taste.

--Beman