
Message du 20/11/10 16:49 De : "Edward Diener" A : boost@lists.boost.org Copie à : Objet : Re: [boost] review request: addition to type_traits libraryofhas_operator_xxx
On 11/20/2010 4:15 AM, viboes wrote:
Edward Diener-3 wrote:
snip...
Alternatively I could even see putting all the operator traits in their own namespace of 'boost::operators', dropping the 'operator_' in their name, and allowing the end-user to surface them to just the 'boost' namespace via a using declaration as they like. But then again, I am a very strong supporter of namespaces and allowing the end-user to expose what they want from namespaces via 'using'.
Note that interfaces must be designed not only to satisfy the developer but to improve the readability. If a namespace is used, as a user I will need to be able to decipher that
has_division::type
intends to be "has division operator". I will find much more clear If I have to read
has_division_operator::type
IMO, namespaces in this case doesn't make the code more readable.
'boost::type_traits::operators::has_division::type' seems readable to me. Or if you think this is too long you could use a namepsace alias and do:
namespace tt_operator = boost::type_traits::operators;
and then 'tt_operator::has_division::type' is short enough.
Surely you have heard of that famous saying, "Readability is in the eye of the developer" .
When several developers work together this is more subtle. One developer could write has_division::type and the others could find this not enough explict. With has_division_operator interface there is no direct possibility of this shortcut. Don't forget tha the code you develop one day, will be maintained most of the time by others later. Best, Vicente