Re: [boost] [review][Fit] Review of Fit starts today : September 8 - September 17

Subject: Re: [boost] [review][Fit] Review of Fit starts today : September 8 - September 17
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2017-09-18 15:45:45

> On 18. Sep 2017, at 16:45, paul <pfultz2_at_[hidden]> wrote:
> 
> But if I use the FunctionUtilities, I would find calling
> `boost::function_utilities::pipable` or
> `BOOST_FUNCTION_UTILITIES_STATIC_FUNCTION` to be just too long. 
> 
> I think HigherOrderFunctions is much more descriptive, and then I could use
> the namespace `hof` for short.

I hope I am not bike-shedding here. I do believe that names are important, because they are the first thing you see of a library, and I believe that "obviousness" is an important factor.

I can see where you are coming from, but let me try to defend the name "Function Utilities" a bit, because although I think that using another abbreviation like "hof" is better than "fit", "hof" still leaves me without a clue at first sight.

You argue against long macro names and long namespaces, but in my coding experience, people use short aliases for boost namespaces in any case, e.g. `namespace bfu = namespace boost::function_utilities;`. Even for `boost::fit` or `boost::hof`, I believe that people will make an alias, because of the repetitive `boost::` prefix. So the length of the namespace name is not an important factor IMHO. Also, we already have long namespaces in Boost, like boost::program_options, which people happily use.

About the macro names, ok, you have a point, BOOST_FUNCTION_UTILITIES_* is longer than BOOST_HOF_*, but if I type it once, my editor is going to auto-complete the long name for me for the rest of the project.

There is another general argument in favour of more descriptive names, which I like: "code is written once, but read many times". Therefore, in a tradeoff between readability and writability, it is not bad to lean towards readability. If I was a random guy that reads some code that uses your library, I would scratch my head less at BOOST_FUNCTION_UTILITIES_*.

> Also, the word 'utility' is not very descriptive, and I would prefer to move
> away from using it. Boost.Utility contains random things in it that are
> unrelated, and I don't want this library to be described as a collection of
> random and unrelated functions.

I tentatively agree that "Higher Order Functions" is better than "Function Utilities", but yeah it is even longer to write out. Right now we don't have a library with a three word name, this could be the first! The arguments in favor of long names also hold for `boost::higher_order_functions` and BOOST_HIGHER_ORDER_FUNCTIONS_*.

Best regards,
Hans

PS: What if the library was called Boost.HigherOrderFunctions, but the namespace and macros would use boost::hof and BOOST_HOF_*? Would that be an option?