[Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation

[Jeff Squyres]

On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote:

> I have been quiet on this debate but I am to the point
> that I feel a need to speak up. I think the "significant
> changes" reason is a canard (I think Brian and Jeff
> believe it but it is still a red herring for the most
> part). The changes to support it are not significant.
> You can implement it by casting it away early.
>

The changes *are* significant.  I count 90 top-level MPI API functions  
that are affected by this proposal.

The bar for 2.2 is "trivial" implementation efforts, no?  This is not  
trivial.  The MPICH diff was ~10,000 lines.  Apparently, they chose to  
go above and beyond the requirement and propagate const to lower  
layers (vs. casting it away immediately), but still -- if a 2.2 change  
can inspire a 10,000 line diff, that just seems like it doesn't meet  
the spirit of the "trivial" implementation requirement.

Indeed, in doing the "simple" cast-it-away-immediately approach  
implementation, editing and testing each of the 90 functions will  
require a good amount of effort.  Sure, the first-wave addition of  
"const" across all of the affected functions is probably relatively  
easy -- one code monkey and several hours.  But how long will it take  
you to find the one place where you put "const" in the wrong  
location?  How long will it take you to write new tests to verify the  
const-ness in all the right places?  To be clear: it's a "not  
significant" change to a code monkey.  But try to tell your QA guys  
that this is not significant -- they'll freak out.

Hence, if you take the overall scope of both the change and the  
additional testing to validate this change, this is a large scale  
implementation effort.  I just don't see what the rush is to get this  
into 2.2.

I think Brian makes several good arguments, one of which is: those who  
want const can put it in today.  It hypothetically shouldn't break any  
existing user codes (this is the code monkey in me talking, not the QA  
rep), and those implementors who want it for stronger contracts can  
have it.


-- 
Jeff Squyres
Cisco Systems