| Author |
 Topic  |
|
|
Dusan
Whole Tomato Software
Slovakia
177 Posts |
 Posted - Dec 02 2013 : 07:30:13 AM
|
I am not sure if this is already in consideration, but it would be fine to have a way to rename all enum entries common portion at once.
For example, if there is enum:
enum TextColor
{
TC_Red,
TC_Green,
TC_Brown,
TC_Blue,
TC_Black,
TC_White,
...
};
And lets say that I want to rename all its references in code,
I could be able just click on "TextColor" and choose "rename members common part" and VA X would provide rename dialog with "TC_" portion.
If I then type "TextColor_", I would get renamed all enum members references in project/sloution to changed enum:
enum TextColor
{
TextColor_Red,
TextColor_Green,
TextColor_Brown,
TextColor_Blue,
TextColor_Black,
TextColor_White,
...
};
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Dec 06 2013 : 8:49:20 PM
|
I like this, and maybe, it could be used on multiple symbols as well. I have put in a feature request for this to see what the developers make of it:
case=78833
However, since normally a list appears with renamed references, maybe we would need multiple lists which isn't practical. Blind rename is an option here though, but it has its drawback of not having a chance to spot a potential renaming problem.
All in all, it would do a lot more change in the code at once which is great but potential problems would be multiplied. |
 |
|
|
jay.carlton
Ketchup Master
USA
65 Posts |
Posted - Dec 10 2013 : 4:50:01 PM
|
There might be a use case or two for some general prefix recognition, enforcement, or modernization options. For example, if I have a number stand-alone functions starting with a Foo prefix, maybe I could have an operation that renamed them all and moved them to namespace foo or class FooUtils?
Once scoped enums in C++11 become more widespread, I might actually want the reverse capability of what DusanDusan is asking for. That is, to replace the prefix of each enum member with a strongly typed enum qualifier. I think the syntax would be TextColor::Red, assuming the enum declaration was changed to an "enum class" declaration. Haven't tried this yet, though. |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Dec 10 2013 : 9:36:42 PM
|
Excellent ideas, I like them  They're great use cases for the feature. I have added them to the case, so they can serve as a rationale as well, for the feature.
I wouldn't merge with move to namespace, though. For example, moving independent methods to a namespace doesn't make much sense. Users will probably want to move the whole class to a namespace instead, first. You can still use refactorings to move stuff to namespace providing you will have a separate refactoring for that in some point in the future. |
|
|
|
jay.carlton
Ketchup Master
USA
65 Posts |
Posted - Dec 11 2013 : 09:34:37 AM
|
quote:
Originally posted by accord
I wouldn't merge with move to namespace, though. For example, moving independent methods to a namespace doesn't make much sense. Users will probably want to move the whole class to a namespace instead, first.
I think there are some advantages of moving stand-alone methods to a namespace and bypassing a class. You still get shorter method names, and the compiler and other tools can both understand and enforce the naming convention. It's common I think for C or pre-namespace C++ code to be organized by naming convention only, and this kind of maneuver might make it easy to do more object-oriented refactorings down the line.
If you move them directly to a new utility class, you'd probably want to make them static members, but there are advantages for doing that as well.
But ultimately, I think having a general idea of "target scope" for rename and extract operations would be helpful for larger solutions. So I could have Rename to namespace, extract method to {private method, anonymous namespace free function in implementation file, globally exported free function in lower level project, etc.}. |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Dec 12 2013 : 10:08:15 PM
|
I meant class methods that are already part of a class
You are right about moving scope, but first, we should have a separate moving scope refactoring first. :) So we can consider creating a composite one. |
|
|
| |
Topic |
|
|
|
Replace common portion in enum
