Unify naming of channel_multiplies_t vs pixel_multiply_t

[mloskot]

The two are very similar multiplication operations, one for channels and one for pixels, but they are named differently, quite confusingly

gil/include/boost/gil/extension/numeric/channel_numeric_operations.hpp

Lines 75 to 76 in 11c897b

	template <typename Channel1, typename Channel2, typename ChannelResult>
	struct channel_multiplies_t

vs

gil/include/boost/gil/extension/numeric/pixel_numeric_operations.hpp

Lines 79 to 82 in 11c897b

	template <typename PixelRef1, // models pixel concept
	typename PixelRef2, // models pixel concept
	typename PixelR> // models pixel value concept
	struct pixel_multiply_t {

Ideally, if the naming could be unified.

---

For example:

1. Rename channel_multiplies_t to channel_multiply_t
2. Alias channel_multiplies_t to the latter
3. Mark the channel_multiplies_t as deprecated (compile warning)

UPDATE: See the naming discussion below.

---

@stefanseefeld thoughts?

[marco-langer]

The same problem occurs with the divide operations: There is pixel_divide_t and channel_divides_t.

In the standard we havestd::multiplies / std::divides and not std::multiply / std::divide.

Which solution is preferred?

[mloskot]

In the standard we have std::multiplies / std::divides and not std::multiply / std::divide.

Good point.
It looks to me these are named as in "this functor multiplies a and b" and it makes sense.
But, why there is std::negate instead of std::negates as "this functor negates"?
I always thought the C++ standard prefers singular/impersonal forms like in std::accumulate and not "this std::accumulates", etc.
That is why I suggested multiply instead of multiplies, but I am not going to die hard for it ;)

Let's go for the C++ standard naming and unifying this way: channel_<std equivalent name>_t

[marco-langer]

Just a guess, but having std::accumulate as an algorithm and std::multiply as a functor would be quite confusing. People would expect std::multiply to be an algorithm as well.

(std::negate does not follow this logic though)

[mloskot]

People would expect std::multiply to be an algorithm as well.

Yes, that's reasonable explanation.

Let's have channel_multiplies_t then.