RE: [boost] Why are we looking for a boost/Loki smart-pointer merginf?

From: AlisdairM (AlisdairM_at_[hidden])
Date: 2002-01-25 16:04:29

-----Original Message-----
From: Lee Brown [mailto:lee_at_[hidden]]
Sent: 24 January 2002 22:57
To: boost_at_[hidden]
Subject: Re: [boost] Why are we looking for a boost/Loki smart-pointer
merginf?

> Ideally, shouldn't policies _increase_ clarity?  The concept being "turn a
> big problem into many small (easily understood) ones."  I would think that
> policies should make the code _clearer_ in some sense.  Although policies
> tend to be abrstractions of specific notions and abstractions are more
> difficult for the human mind to understand,  the code itself should be
> _simpler_.

In what way does introducing policies and abstraction simplify and clarify
the boost::scoped_ptr.  The task of this class is incredibly simply, is a
single well-defined abstraction in its own right, and doesn't need confusing
with a lot of policies and extra concepts that are irrelevent to it.
*unnecessary* abstraction is a great way to obfuscate code.

OTOH, witness the debates about a better shared_ptr.  Here is a different
idea that can indeed benefit from worrying about all the issues that
policies encapsulate for us.  It can be generalised in such a way that it
happens to cover the case of the scoped_ptr too, which is a nice validation
of the concept, but still a step back for the scoped_ptr (to my mind)

I hold out for retaining scoped_ptr as-is for the same reason I would work
out the range a catapult can throw a rock using Newtonian Mechanics rather
than quantum theory or General Relativity.  Both more modern theories could
be used to more accurately model the problem, but they bring in a lot more
machinery that hides the real problem while adding little of value, the
Newtonian model will be well within any bounds allowing for variable wind
resistance, irregular rocks etc.

AlisdairM