[geos-devel] const-correctness

[strk]

mbdavis wrote:
> My personal opinion is that it's probably more trouble than it's worth, at this point.  As the FAQ points out it's a bear trying to retrofit const correctness.  
> 
> What sort of bugs was it catching?

Modifications made on objects passed for read-only purposes..
Can't remember exactly, but I had to define filter_ro, filter_rw
and apply_ro, apply_rw because there was an inconsistency between
the two about whether they were keeping the passed argument const.

But mainly it has to do with ability of read/mantain the code since
I've the impression that the code has been changed many times for
each method to touch/non_touch given argument copy/non_copying it
and the like. If introduction of 'const' makes it clear what to do
and *sometimes* forbid you from touching an untouchable object
I think it is worth introducing.

Yes, it might be *very* long to do in one shot, but can be done
for one particular interface down to its diramation in reduced time.

For example, if we'd like to fix the semantic of GeometryCollection
constructors we should use 'const' to set it. And... yes... comments
above each method should do more the contrary of 'const'.

--strk;