Sat 16 Jul 2016 02:52:23 AM UTC, comment #8:
JWE, I'm still not quite sure what you want done.
Let's use the example of "exit_status" from octave_exit_exception::octave_exit_exception(int, bool).
That class currently has a private member variable m_exit_status, a public function exit_status, and (as if by accident) a parameter exit_status.
We can't rename the function m_exit_status, because that conflicts with the member variable name.
We can make a potentially large change, and rename the member function to something like get_exit_status, or we can make a small change to fix the "accident" and rename the parameter, to something like p_exit_status.
I'm happy to do whichever you suggest (except the impossible one, which is how I interpret your previous requests), but will argue below that changing the parameter is the best approach.
First, I don't see why it is not a problem to have a parameter named the same as a member function. (I know this is something we cannot change...) Consider the code
That is unambiguous to the compiler (which is why it is not an error), but misleading (which is why it should be a warning).
We don't even need to have function-type variables. Simply being told that a call "exit_status ()" is invalid is misleading.
Second, if devs are using a version of gcc that doesn't warn of situations like the above, then they are likely to create new constructors for existing, possibly widespread, classes that cause this ambiguity. A global policy of changing the member name would require widespread changes to the code, to essentially work around an accident. (That doesn't mean we can't do it in this particular case.)
Oh, and "_m" was just a typo. Sorry for any confusion.
|