I guess it will be a little painful to update quite a few functions, but const correctness is important, specially when reasoning about code and in multi-thread environments.
Not sure if this has been already discussed, what do you think?
My experience is that const correctness is often an all or nothing decision. If you start adding const keywords then things will break until you make sweeping changes in the entire code base and also in external code that use it.
Const correctness helps with documentation and avoiding some bugs, so it is good (I would not say it is important), but introducing it would be a huge change, which has to be planned carefully. Also note that any change that forces application developers to modify their code is extremely frustrating if there is no proportional gain (significant new features, better performance, etc.).
GetNumberOfPoints may be called at many places, very frequently, so I would not risk any performance impact by adding one more level of indirection. The non-duplicating code is longer and harder to read. So, I would leave the current implementation of the non-const GetNumberOfPoints as is.
Several times I’ve been disappointed when I wanted to make some
function in our code const-correct, but could not since it calls some
VTK function on a member, and VTK is not const-correct. I understand
of course that a sweeping refactor of VTK would create a lot of pain,
but I would welcome baby steps like these where feasible. I think in
library code one should always strive to be const-correct, because it
leaves the library user a choice, whereas “everything non-const” does
not.
If I had to choose what VTK developers should spend their time with, const correctness would be pretty low on the priority list compared to improving performance or adding features (oriented image data, robust polydata Boolean operations, GPU-accelerated filters, etc.).