Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Feature Requests
 Rename declaration and definition of params

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
shippy Posted - Nov 18 2014 : 11:39:41 AM
I notice when I use the rename functionality to change a function's name in its header declaration, it includes the implementation definition as well, which is expected. However, if I change a function's parameter's name in the header declaration, the rename dialog does not include the implementation. Is there an option to do this or is it not currently supported?
5   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Nov 24 2014 : 2:41:41 PM
If you use Change Signature then after updating a parameter name, both the declaration and implementation will use the same name, so in this sense this has already been done. Change Signature knows it is looking for signatures, and that they can be different.

Rename is designed to rename a variable, and expects that variable to always have the same name. Here the solution is for Rename to realise it should be doing a Change Signature, and to act accordingly. I was mainly just trying to explain why this is not quite as simple as it sounds at first. We are looking to fix this, its just a matter of getting there.
Mordachai Posted - Nov 24 2014 : 10:32:39 AM
Seems to me that it is important to be able to set some policies.

For myself - I'd prefer that they be in sync - the ones that aren't are simply because of human error - changed one place but not the other - not because that's a "feature" - just because I or my fellow programmers didn't replicate the change to the other location (from h -> cpp or vice verse).

I know that this is problematical in itself because there could be a thousand policies - and that could grow to unsupportable size. However, I think it's a balancing act - you have to pick and choose what you're going to dictate (the limits of your tool) and what you're going to support by policy / preference.

In my estimation, aving different headers and .cpp declarations is just bad style. And although I'm sure there is "that one guy" who loves this "feature", he's a tiny minority and is simply practicing very poor style (maybe he should reconsider regressing to C language, where even headers are not necessary?)

I kid - but seriously - having different definitions of the same thing should be illegal. That they aren't is a left-over from C, not a laudable feature.
feline Posted - Nov 21 2014 : 4:30:00 PM
We are looking at this, but its worth remembering some people work with code where the identifier names are not given in the header file, only in the cpp file. Also you have code where the identifier names are different in the cpp and header files. Both cases compile just fine, even if they do make me wonder why someone would want to do that.

The best general advice I can offer here is to briefly consider the results list that will be updated in the Rename dialog, to see if it looks reasonable before moving forward, since this should give you a clue if you are running into one of these edge cases where the result won't be the one you are expecting.
Mordachai Posted - Nov 21 2014 : 2:22:58 PM
Just wanted to throw 2c in as "yes, please." I get this confused often, and I'm never sure if my change will fully take effect or not. Header / cpp should be kept identical (w/ special handling for default values of course) at all times, irrespective of whether the transform was invoked from header or implementation.
feline Posted - Nov 20 2014 : 4:46:59 PM
Unfortunately this is currently a known limitation, but it is one we are looking to fix at some point:

case=1140

For now, the best work around is to use Change Signature to rename the parameter instead, which is designed to update both the declaration and the implementation, regardless of which you trigger the command from.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000