Hi Bernhard,

For the distance algorithm (the one I handled the same way), the advantages for the user were more obvious. For this one I agree they're less so. Let me first summarize what they're supposed to be:
* [for the user] More user-friendly - for distance, things like pythagoras<Point1, Point2, CalculationType> became pythagoras<CalculationType>
* [for us] (that was the first motivation) more flexibility within the library - manipulating the strategies with the algo dispatch mechanism is made easier, and some internal tricks are made irrelevant - a recent communication with somebody wanting to contribute a change confirmed the new approach was better
* [generally] Less template instantiations - good for compile times and to avoid reaching number of sections limit on some implementations

Reason 2 is really the main one, as I was blocked on several developments because of that.

But I must admit that in your case, and for this algorithms, it's less appealing. In the case of an end user it's OK (translate_transformer<mypoint, mypoint> would be replaced by e.g. rotate_transformer<double, 2, 2>). But in your case you're using template point types so it gets ugly indeed.

I've looked at the code and those template parameters are indeed needed as class level - they are basically remaining parts of the point types that we couldn't move down to function level. So I think the situation would be a good candidate for maker functions (a la make_pair). This is something I intended to try for distance strategies as well, but here I can see it's even more relevant. Thanks to maker functions, our code could basically become (using C++11 syntax, just replace with BOOST_AUTO otherwise or pass the strategies directly):

auto rotate = make_rotate_transformer(...);
auto translate = make_translate_transformer(...);
bg::transform(..., rotate);
bg::transform(..., translate);

That would automatically return the right type of strategy, depending on the type of parameters passed (so you'd need to use the same type as what your points use, does that make the code even uglier in your situation?) and the number of parameters (e.g. the 9 params overload would return a strategy for points of dimension 2).

Barend: what do you think of this?
Bernhard: would this help at all?

Regards
Bruno