Well, you should at least add examples in the form of regtests, and in case of something like Bezier::solve_point it would make sense to take stock of what there is on the C++ side and see whether Bezier::solve_point would make sense as an integral part of a larger whole that gives a convenient toolbox in connection with other Bezier-related functionality, and then plot what that whole should entail. Basically try to aim for something making sense as a whole and not just for supporting your particular application that is so specialised that it does not make sense as a MR.
Thanks, will do. (Also thanks to Jean for reminding me of the semi-related discussion of Valentin's MR.)
In this case, I think it's almost the other way around: Since Jean removed the duplication of bezier-related code in C++ and Scheme, we have lily/bezier-scheme.ly, which consists only of wrappers around Bezier::extract and Bezier::extent. And to be honest, I rather think that Bezier::extract is actually not that useful without Bezier::solve_point (but I know that Mike managed to make good use of the former without needing the latter in his code for woodwind diagrams).
Lukas
