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: paul (pfultz2_at_[hidden])
Date: 2017-09-18 16:27:12

On Mon, 2017-09-18 at 17:45 +0200, Hans Dembinski wrote:
> 
> > 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?

Yea, thats what I am considering.

.