Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision

Subject: Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-04-21 15:42:50

Barend Gehrels wrote:

Yet another round.  Oh boy.  I'll address the points you (re)raised, but I plan to stop after this.  There's really not much more we can say, unless there's a sudden epiphany.  We've covered most everything that can be covered, so I'll just leave things for Frédéric to sort out after this.

If you haven't done so, do try the thought experiment I suggested in my reply to Joachim.

> There are two things: the names  and the prefix. And they are
> related.
>
> About the prefix: I don't like can_call_. It is novel as
> Joachim says, and AFAIK not widely used, and looking a bit
> awkward (in my opinion). In such cases I normally use
> "supports", so: supports_addition, supports_equal,
> supports_not. It is not shorter (neither longer) but reads more
> smoothly.

"can_call_" is novel, but I don't find it awkward.

"supports_" is a bit vague, but passable.

> Next step: inserting the "operator_ " is even more clear.

Now you run afoul of Joachim and others (including me).  I don't think that adds anything useful.  It just makes the name longer.

> Next step: then "has_" is more convenient, because complying to
> existing practice. So: "has_operator_not". Perfect.

Nope.  As has been noted before, that implies ownership.  A global operator doesn't belong to anything, so nothing "has" the operator.

> But "has_operator_addition" is not perfect, is awkard.

Yep, but "can_call_addition" works.  You could argue that it should be "can_call_addition_operator" but then we reopen an earlier discussion.

> This shows the problem, the prefix and the name are related:

They are related and the prefix must not only be sensible, but work for all of the operators, not just a few.

> it should then be has_operator_plus... It is not the
> "operator_addition" it supports, it is the "operator_plus" it
> supports (doing an addition).

If you go that route, as we've discussed already, then you must use symbol names for all operators and they don't all have convenient names.  You'd have "asterisk" or "star," "slash," "percent," etc.

> Why should it be
> proto::plus and can_call_addition?
> proto::equal_to and can_call_equal?
> proto::shift_left and can_call_left_shift
>
> Very confusing.

You don't find the admixture of "plus," "multiplies," "equal_to," "negate," and "unary_plus" confusing?  I certainly do.  To use "plus" implies "asterisk," "equal," and "unary_minus" for a consistent set of names.

I missed my chance to object when Proto was being reviewed, but I hope to do better with TypeTraits.  Do the thought experiment and see whether the "can_call_" names aren't about right.

> OK, it is not consistent among Boost libraries (which is bad),
> but then take the library having the complete list (which is
> probably Proto).

That's unfortunate, but all too true.  However, Proto is not used nearly as much as TypeTraits, so I'm not sure Proto must be the prototype.  I've used TypeTraits often, but have yet to use Proto, as one datum.

> So I prefer what (if I'm right) has been proposed before:
>
> proto::plus and has_operator_plus
> proto::equal_to and has_operator_equal_to
> proto::shift_left and has_operator_shift_left

With such a list and infrequent use, I know I'll always have to refer to the documentation to figure out the names.  Such "consistency" fails to help me in any way.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.