Hi Frédéric, 2011/4/20 Frédéric Bron <frederic.bron@m4x.org>:
I have updated the type traits extension for operators: - new names beginning with can_call_ - simpler names for helper traits - fixed typos in documentation - dont_care as default return type; check for exact void return when Ret=void - names of template parameters now begin with a capital letter followed by lower case letters (RHS->Rhs, LHS->Lhs, RET->Ret...) [..] It is not finished; more to come...
Frédéric
[..]
+ can_call_addition - can_call_subtraction * can_call_multiplication / can_call_division [..] += can_call_addition_assignment [..]
PS: Please, find below the list of chosen names. I would appreciate not to start again a discussion about the good/bad of this choice.
I am sorry that I don't live up to your expectations here, but I think that you did not complete the discussion about the rationals of good naming for those names and that I did not see you addressing arguments that I raised, specifically those that prefer inter library consistency over personal taste...
I am sure there are at least 2 persons that like it, sorry if not more...
... and that the naming issues on operator traits shall not be a question of taste, whether someone likes them or dislikes them temporarily, but a question of usability and cross library simplicity that honors the choices made by others in the past and acknowledges the fact, that those choices can not be altered without breaking existing code. When I read your list of name choices I noticed that I got pretty annoyed. And then I wondered why this issue upsets me so much. I realized that I value the effort of maintaining naming uniformity, consistency and simplicity *across* libraries a lot and I think it is pretty unwise to sacrifice that value for temporary and personal matters of taste. Moreover I feel that important arguments and efforts pursuing that goal have not been addressed in the discussion. I don't think it is boost style or good style in general to end an open discussion like this by declaration of a final list. Your list of final namings (in this thread) introduces a number of names that are neither used for the analogous identifiers in the standard nor in Boost.Proto or other boost libraries. I see you deliberately introducing a diversification of names without giving a justification. (1) I think that this ignores my main argument that cross library naming consistency is more important than local taste considerations. (2) I also think that you ignore choices of other language and library designers that have been made in the past, including the choice to value consistency over personal taste. Implied in ignoring those choices is the attitude that their choices from the past are inferior to your current choices. (3) I feel that efforts made to support cross library naming consistency by e.g. setting up the wiki page are ignored and unused. (4) The new choices are inconsistent to the standard and prevailing boost libraries and are in addition inconsistent in themselves: (4.1) I see you using prefer the grammatical form of substantives now. Hmm, ok. So addition for plus, assignment for assign etc. If you choose "addition" instead of "plus", you should consistently also use "conjunction" instad of "and", "disjunction" instead of "or". If you use "assignment" instead of assign, you should also use "equality" instead of "equal" and "negation" instead of "unary_minus" and so on. (4.2) Instead of reducing diversity and enhancing cross library naming consistency you seem to introduce new problems. (5) I think the rationals and rules you are working with for naming choices are in themselves inconsistent and changing. (5.1) In the last version of your docs you justified your name choices referring to choices made in the standard (although not following this rule consistently), which I strongly second. Now your seem to abandon this maxim completely. (5.2) In the review version of you library extension, you chose the has_ prefix in order to be consistent with you parent library that uses the same prefix for many of its traits. Now you are introducing inconsistency against your parent library using a novel prefix can_call_. (6) If we consistently chose to the best of our current knowledge names and ignoring prevailing names, what would happen. Suppose we had a bunch boost authors each of them working on a library that has some names refering to operators. (6.1) Author A finds substantives unfortunate and feels the rule that a name associated to a operator should be completable to its concept name and she thinks that prefix has_ is nice because Boost.Typetraits uses is already: She chooses has_add, has_subtract, has_multiply, has_divide,... instead of can_call_addition, can_call_subtraction, ... (6.2) For a different library referring to operators in some way author B considers, that operators can be implemented for different semantics. Therefore he chooses for extremely good reasons general names. He loves his names to be auto sorted by those general names first, so he chooses a suffix: for + : combine_is_applicable, - : uncombine_is_applicable, * : product_is_applicable, / quotient_is_applicable (6.3) Author C has the insight, that authors before her were ignorant of the fact, that any specific or general name suffers from that fact that implementing a special semantics for the operator may lead to a wrong meaning anyway. So deliberately she chooses names that refer to the syntactic nature of the op sign: For +: has_plus, -: has_minus, *: has_asterisk. /: has_slash, ^ : has_caret etc. (6.4) Author D loves Haskell and short concise naming. He decides that the applicability of an operator is nicest expressed by the third form of a verb like "adds" which means that addition can be called on some matching signature of types. So he chooses: For +: adds, -: subtracts, *: multiplies, /: divides (6.5) Author E ... etc. (6.5) Every Author X is deeply convinced of their points of view and finds some support in discussions on the list, so they decide, that their personal superior choice of naming is indispensable. So each of them implements their own superior naming in their library ignoring their fellow authors and the namings that have been chosen in the past. They might regret a little that very similar things are now expressed more and more diverse in the lands of c++ and boost and that users might constantly stumble over problems related to that naming chaos. (7) Behavior described in (6) not only is malicious, because it leads to naming chaos where users not only are hampered but also disgusted. It also leads to hodgepodge of different rules and rationals. In contrast to that a rule that aims to maintain inter library naming consistency is very simple (See my concrete proposal here https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators). I'd like to propose a meta rule A naming consistency L that is local, temporary and specific has to be sacrificed for a naming consistency G that is global, durable and general, even if G contains partial inconsistencies from a current point of view. Local: Single library Global: Cross library and/or language stadard Temporal: New library Durable: Existing libraries are affected. Specific: A current discussion. Specific point of view General: A general process relating to many libraries Finally as I have done before I'd like to stress that this is not a small thing. Since operators are at the core of the language, I expect that your operator type traits will be used by thousands of developers for years and decades. Naming inconsistencies will make it more difficult for them to memoize, use and manipulate operator traits in their programs. This means that in choosing names you have a responsibility not only to serve your taste but to serve the users. Inconsistency is very easily created but it is impossible to get rid of it, once your extension is in the boost release and people start writing programs. So my request is this: Please use those names that are the *most unifying names* with respect to the language standard and the existing boost libraries. These names or name components are contained in the MUP column of the wiki page: https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators ... and please don't confuse me further ;-) As I just looked to the wiki page I fould that meanwhile there are *3* different versions of *your* proposals for your names! (1) The list in this thread. Flavor "substantives" (2) The list edited by you in the wiki page. Columns proposed new names and (3) a new table with different names yet again. I hope you'll get my point. Please don't take it too personal, if I appear a little harsh. It's because I think inter library consistency really matters a lot. Confused and frustrated .... Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de