|
Boost : |
Subject: Re: [boost] review request: addition to type_traits library ofhas_operator_xxx
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2010-11-20 11:56:56
> Message du 20/11/10 16:49
> De : "Edward Diener"
> A : boost_at_[hidden]
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk