Well, here is list of release steps I have for the refactoring assistant. They are made in such a way to maximize the amount of functionnality provided in face of the amount of development required.
Those all works at the method level and can be done by parsing only the method body (which is mostly done at the current time).
IntroduceExplainingVariable may raise some formatting issues.
2) Class refactoring that change only the class:
- ExtractMethod
- InlineMethod
- SelfEncapsulateField
- ConsolidateConditionalExpression
- DecomposeConditional
- RenamePrivateField
- RenamePrivateMethod
Those work on a single .cpp/.h (no project management needed yet).
3) Class refactoring that creates new classe
- ExtractClass
- ExtractInterface
- ExtractSubclass
- ReplaceDataValueWithObject
- ReplaceMethodWithMethodObject
Those still work on a single .cpp/.h. On the other they creates new class and file, which make them slightly more complicated to deal with.
4) Class refactoring that use more than one classes
- InlineClass
- ExtractSuperClass
- MoveField
- MoveMethod (using delegation)
- PullUpField
- PullUpMethod
- PushDownField
- PushDownMethod
Those works on a specified set of .cpp/.h.
5) Project wide refactoring
- RenameFreeFunction
- RenameMethod
- RenameField
- RenameClass
- RenameType (typedef, enum...)
- ...
Those works on any .cpp/.h of a given project. We may need to introduce some form of symbol database to help performance, but we'll see when we get there.
Notes that the refactoring listed may or may not be implemented in the specified step. The lists are just used to shape what the content of a step is.
All those steps will allow us to make the system a little more complex at each step. When we will be done with step 4, we should have a fairly good ideas of what is needed to achieve step 5.
Baptiste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A few comments:
My idea is to keep the number of global refactorings to a minimum, since global parsing appears more complicated to me. This may come at the price of splitting some refactoring in two parts (i.e., refactoring the refactorings).
- Inline Method might be global if the method isn't private;
- Refactorings in Step 4 work on 2 classes (4 files) only;
- RenameMethod and RenameField can be thought of as working on a single class (using delegation).
- Rename Class can be local if we introduce a global refactoring InlineTypedef (just if that's useful for anything else)
- IMO ConsolidateConditional is method-based (usually followed by Extract Method)
- Another Method refactoring is Split Loop
However, it's a good list to start with.
Sven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as I can see (100 documents in the mailing list).
This is the discussion of features for the refactoring operations. Correct me if there's some news about that thing...
local renaming is in many cases only a work of search and replace ... well, just in case not so many identifier names are nearly simular.
So global renaming is the most important thing, since this is real refactoring.
But I understand the problems with the parsing. It could lead to a refactoring tool which is project based, and has to collect all information before it can start such operations.
so the start with just something that works very early is a good idea - but as soon as possible there should be a decision how to handle global refactoring operations.
but after all - first i have to look through the sources, to understand what I'm talking about ;)
-- andre baresel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Renaming local variable correctly requires to find local variable declarations, scopes and usages. Once this is done, it is basically a simple matter of replacing the old name by the new one.
For us, this means that we can focus on the parsing/analysis for now, and don't have to bother with a 'rewriter'.
This refactoring is already working fairly well. The next to be tackled will probably be ReduceLocalVariableScope which in combination with RenameLocalVariable is very useful to deal with long method.
The analysis tools developped for the RenameLocalVariable refactoring are nearly enough to implement the ExtractMethod refactoring (we now which local variables are used, were it is declared...). Though, we still need to have a fairly complete parser (parsing class and method declaration) before we can do this.
My though is that we can learn how to do global refactoring by doing refactoring with a smaller scope but with similar problematic (RenamePrivateField / RenamePrivateMethod).
Doing global refactoring rise a lot more issues: managing a list of project files, multiple files undo/redo... This take a lot of time to do correctly.
Baptiste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Renaming local variable correctly requires to find local variable declarations, scopes and usages. Once this is done, it is basically a simple matter of replacing the old name by the new one.
For us, this means that we can focus on the parsing/analysis for now, and don't have to bother with a 'rewriter'.
This refactoring is already working fairly well. The next to be tackled will probably be ReduceLocalVariableScope which in combination with RenameLocalVariable is very useful to deal with long method.
The analysis tools developped for the RenameLocalVariable refactoring are nearly enough to implement the ExtractMethod refactoring (we now which local variables are used, were it is declared...). Though, we still need to have a fairly complete parser (parsing class and method declaration) before we can do this.
My though is that we can learn how to do global refactoring by doing refactoring with a smaller scope but with similar problematic (RenamePrivateField / RenamePrivateMethod).
Doing global refactoring rise a lot more issues: managing a list of project files, multiple files undo/redo... This take a lot of time to do correctly.
Baptiste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was just seeing that -- "Next Attemp" Thread which also discusses my suggestions.
I think this way of discussing really hurts, if you just come in to a project ---
It's not really nice to read about 100 postings --- and even more if you come in later.
-- andre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, here is list of release steps I have for the refactoring assistant. They are made in such a way to maximize the amount of functionnality provided in face of the amount of development required.
1) Method refactoring:
- InlineTemp
- RenameTemp
- IntroduceExplainingVariable (may be)
Those all works at the method level and can be done by parsing only the method body (which is mostly done at the current time).
IntroduceExplainingVariable may raise some formatting issues.
2) Class refactoring that change only the class:
- ExtractMethod
- InlineMethod
- SelfEncapsulateField
- ConsolidateConditionalExpression
- DecomposeConditional
- RenamePrivateField
- RenamePrivateMethod
Those work on a single .cpp/.h (no project management needed yet).
3) Class refactoring that creates new classe
- ExtractClass
- ExtractInterface
- ExtractSubclass
- ReplaceDataValueWithObject
- ReplaceMethodWithMethodObject
Those still work on a single .cpp/.h. On the other they creates new class and file, which make them slightly more complicated to deal with.
4) Class refactoring that use more than one classes
- InlineClass
- ExtractSuperClass
- MoveField
- MoveMethod (using delegation)
- PullUpField
- PullUpMethod
- PushDownField
- PushDownMethod
Those works on a specified set of .cpp/.h.
5) Project wide refactoring
- RenameFreeFunction
- RenameMethod
- RenameField
- RenameClass
- RenameType (typedef, enum...)
- ...
Those works on any .cpp/.h of a given project. We may need to introduce some form of symbol database to help performance, but we'll see when we get there.
Notes that the refactoring listed may or may not be implemented in the specified step. The lists are just used to shape what the content of a step is.
All those steps will allow us to make the system a little more complex at each step. When we will be done with step 4, we should have a fairly good ideas of what is needed to achieve step 5.
Baptiste.
A few comments:
My idea is to keep the number of global refactorings to a minimum, since global parsing appears more complicated to me. This may come at the price of splitting some refactoring in two parts (i.e., refactoring the refactorings).
- Inline Method might be global if the method isn't private;
- Refactorings in Step 4 work on 2 classes (4 files) only;
- RenameMethod and RenameField can be thought of as working on a single class (using delegation).
- Rename Class can be local if we introduce a global refactoring InlineTypedef (just if that's useful for anything else)
- IMO ConsolidateConditional is method-based (usually followed by Extract Method)
- Another Method refactoring is Split Loop
However, it's a good list to start with.
Sven.
As far as I can see (100 documents in the mailing list).
This is the discussion of features for the refactoring operations. Correct me if there's some news about that thing...
local renaming is in many cases only a work of search and replace ... well, just in case not so many identifier names are nearly simular.
So global renaming is the most important thing, since this is real refactoring.
But I understand the problems with the parsing. It could lead to a refactoring tool which is project based, and has to collect all information before it can start such operations.
so the start with just something that works very early is a good idea - but as soon as possible there should be a decision how to handle global refactoring operations.
but after all - first i have to look through the sources, to understand what I'm talking about ;)
-- andre baresel
Renaming local variable correctly requires to find local variable declarations, scopes and usages. Once this is done, it is basically a simple matter of replacing the old name by the new one.
For us, this means that we can focus on the parsing/analysis for now, and don't have to bother with a 'rewriter'.
This refactoring is already working fairly well. The next to be tackled will probably be ReduceLocalVariableScope which in combination with RenameLocalVariable is very useful to deal with long method.
The analysis tools developped for the RenameLocalVariable refactoring are nearly enough to implement the ExtractMethod refactoring (we now which local variables are used, were it is declared...). Though, we still need to have a fairly complete parser (parsing class and method declaration) before we can do this.
My though is that we can learn how to do global refactoring by doing refactoring with a smaller scope but with similar problematic (RenamePrivateField / RenamePrivateMethod).
Doing global refactoring rise a lot more issues: managing a list of project files, multiple files undo/redo... This take a lot of time to do correctly.
Baptiste.
Renaming local variable correctly requires to find local variable declarations, scopes and usages. Once this is done, it is basically a simple matter of replacing the old name by the new one.
For us, this means that we can focus on the parsing/analysis for now, and don't have to bother with a 'rewriter'.
This refactoring is already working fairly well. The next to be tackled will probably be ReduceLocalVariableScope which in combination with RenameLocalVariable is very useful to deal with long method.
The analysis tools developped for the RenameLocalVariable refactoring are nearly enough to implement the ExtractMethod refactoring (we now which local variables are used, were it is declared...). Though, we still need to have a fairly complete parser (parsing class and method declaration) before we can do this.
My though is that we can learn how to do global refactoring by doing refactoring with a smaller scope but with similar problematic (RenamePrivateField / RenamePrivateMethod).
Doing global refactoring rise a lot more issues: managing a list of project files, multiple files undo/redo... This take a lot of time to do correctly.
Baptiste.
I was just seeing that -- "Next Attemp" Thread which also discusses my suggestions.
I think this way of discussing really hurts, if you just come in to a project ---
It's not really nice to read about 100 postings --- and even more if you come in later.
-- andre