Re: [boost] Formal Review of Proposed Boost.Histogram Library Starts TODAY

Subject: Re: [boost] Formal Review of Proposed Boost.Histogram Library Starts TODAY
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-09-25 00:44:04

On 25/09/2018 09:00, Hans Dembinski wrote:
>>> total_size() is less ambiguous than shape(), so I am half-convinced. I would like to have one-word method instead of two-word method.
>>
>> I'm not great in naming things, but perhaps:
>>
>> size()
>> shape    -> capacity()  // as total size including optionally enabled space
> 
> I was also thinking of capacity(), but it may be raising the wrong association? In a sense, it fits: capacity() in a std::vector tells you how much memory for how many items has been actually allocated, while the number of items that you requested is size() items. But people should not think that the existence of capacity() implies that the axis can grow more bins beyond the initial configuration.
> 
> Wider feedback from the list on this would be very much appreciated.

How about "extent()"?

It still conveys a size-like noun, and has association with "physical 
size" in a filesystem context, but without the connotations of 
"capacity()" in a container context.

>> uoflow()    -> tails()
> 
> Currently, over/underflow is configured with the enum class uoflow_type, so it makes sense to call the accessor uoflow(). If this things is called tails(), then we should also have an enum class tails_type. I am not 100 % happy with "uoflow", but I am not sure if "tails" should replace it.

Agreed that consistency is important.  I don't like "tails"; I'm neutral 
on "uoflow" (perhaps a shade against due to difficulty to type).

I believe someone else suggested "excess" or "extra".  Perhaps that 
might be more suitable?