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
>> facilitate communication between policies, the polices aren't "truly
>> orthogonal" in my mind.
>I disagree. If the framework is the only facilitator for communication,
>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
>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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk