Just impressed by the idea developing a refactoring tool I wrote down a list of refactoring issues that might be intresting to be discussed.
It would be usefull to think about the operations and figure out requirements for the refactoring tool. In my opinion it would be a good idea to build up a structured document on this discussion. just write down all ideas and decisions, as well as the requirements that follow out of this.
Just the list as an overview how this document can look like:
Under these operations types you can see differentiations for the symbols in c++:
- namespaces
- modules (files)
- class
- structs
- variables
- functions/members
e.g. Generation --- generate getter/setter
e.g. Extraction --- build an abstract interface class
e.g. Commenting --- build doxygen/javadoc style comment framework for function headers.
If all of you are ok with this, I would just start to create the document and check it in to our documentation.
What about the text format - plain text is not good because links/index & a table of contents would be usefull.
-- andre baresel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your ideas. One thing though. Have you subscribed to the mailing list? I think that some of the ideas that you are talking about are being discussed there. Check the archives, and feel free to post more of your thoughts there.
Cheers
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sven has set up a wiki for this. There is a link to it on our home page (http://cpptool.sourceforge.net/). Though it seems there access write were not set correctly when it was restored (you can not edit page). I look into this this evening (directories under htdocs/wiki needs to be world writable).
I have already added a page discussing a few refactorings.
Baptiste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
btw) Haven't you got any fears loosing the data again ? maybe the most important design decisions should be added in the "Docs" folder ? Just an idea ---
-- Andre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
just found "RefactoringToolArticle" in the rfta module.
Which is quite useful to understand the ideas of the project.
Just some things for Users that come in the project:
1) - it's hard to understand the module structure
(just to make this clear to me: "rfta" is the applic. that tries to implement the refactoring algorithms ?)
2) - it's hard to get some overview documents on the whole project -- the doc-folder of the rfta module gave me a good start !
3) - it would be nice to have a short description on how interessted developers can start with the project sources... Maybe this is solved with point 1) better module structure.
4) - what about the use of the task list just in case more than just two developers are involved.
5) - what about writing down a list of the parallel projects which can be interesting for looking at (I saw these hints from 24.1.2002 somewhere in the forum) ... this would be usefull for new developers
Not just critisism:
- I was impressed by the CppUnit approach which directly starts the tests after compilation ... great !!
- I really see this project has some great ideas (e.g. lazy parsing) ... because of the big amount of work, we need to make these ideas popular, so don't hide them in the application doc folder !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) As far as I understand, the CppRefactory and cpptool module in the CVS repository were previous attempt which were aborted.
Concerning the rfta module structure.
* src/rftaparser is the parser library. It takes some text and produce an AST. Only statements are parsed at the current time.
* src/astdump is an application using rftaparser. It takes a line range and dump the AST in HTML. Just run bin/test.bat for a demo.
* src/rfta is the AST analysis, refactoring and source modification library. It implements the RenameTempRefactoring and provide the TextDocument abstraction to manipulate sources.
2) I'll add a doc describing the content of the doc/ directory.
3) The tests are a good start. rftaparser is mainly a collection of mini-parser. rfta is a bit of a mess at the current time. Interresting test would be RenameTempRefactoringTest, TransformListTest, ScopeGeneratorTest and ScopeHolderTest. I'll try to continue the explanation about the parser on the wiki. More feedback on what need to be explained would be welcome.
4) Let's not. The ToDo page on the wiki and the mailing list provide much more flexibility.
5) Yes. I already started collecting a few links. I'll add a 'Resources' wiki page. There is also a few interesting articles...
I've updated the ToDo page on the wiki and provided a more detailed list of tasks. Some task are of course permanent (e.g. clean up the code ;-) ).
Concerning exposure of the lazy parsing idea, I'm in the process of writing a small document describing the approach used in this project. The lazy parsing is really just a side-effect of the level of detail approach, but it promise to be very useful when doing global refactoring.
The current approach I have for something like a rename class is basically a 'grep' done on all the blanked sources, followed by an analysis of the part of the sources were the class name occurs to see if it is really the class name.
Baptiste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 1) As far as I understand, the CppRefactory and
> cpptool module in the CVS repository were
> previous attempt which were aborted.
[AB::]
I also read this about the CVS not able to delete modules, just need to erase the files in the root directory (which is of cause only possible from sf-people). What about putting a file "depricated.txt" or "not-used-anymore.txt" in the root directories of these modules ?
> Concerning the rfta module structure.
> * src/rftaparser is the parser library. It takes some > text and produce an AST. Only statements are
> parsed at the current time.
[AB::]
I started going through this, and found the idea of ast node mutation very interesting - so this is just a handwritten parser ?
> * src/astdump is an application using rftaparser. It > takes a line range and dump the AST in HTML.
> Just run bin/test.bat for a demo.
[AB::]
works fine, I played arround with it allready.
> * src/rfta is the AST analysis, refactoring and
> source modification library. It implements the
> RenameTempRefactoring and provide the
> TextDocument abstraction to manipulate sources.
[AB::]
ok, I have to check this.
> 2) I'll add a doc describing the content of the doc/
> directory.
[AB::]
this seem not to be a high level priority since there're not much files, the problem was only to understand that this directory is important ;-)
> 3) The tests are a good start. rftaparser is mainly a > collection of mini-parser. rfta is a bit of a mess at
> the current time. Interresting test would be
> RenameTempRefactoringTest, TransformListTest,
> ScopeGeneratorTest and ScopeHolderTest. I'll try
> to continue the explanation about the parser on the
> wiki. More feedback on what need to be explained > would be welcome.
[AB::]
I'm sure some feedback will arise as soon as I'm looking more at the code. At the moment I'm still on the 100 mail-list articles :-) ... just not to ask again questions that have been answered allready ...
> 4) Let's not. The ToDo page on the wiki and the
> mailing list provide much more flexibility.
[AB::]
Ok, I don't known about the features of the TODO implementation of SF. ... I was just wondering why this list is empty ... maybe add some hint in it, where to find the real to-do-list.
> 5) Yes. I already started collecting a few links. I'll
> add a 'Resources' wiki page. There is also a few
> interesting articles...
[AB::]
I see, I also have to look at the wiki more closely -- by the way, what was this data loss of the wiki's ??
... Is it possible to store the pages somewhere in the project, just that we can check out these also as some kind of documentation ?
> I've updated the ToDo page on the wiki and provided
> a more detailed list of tasks. Some task are of
> course permanent (e.g. clean up the code ;-) ).
[AB::]
I known this from my developer team already ;-)
> Concerning exposure of the lazy parsing idea, I'm
> in the process of writing a small document
> describing the approach used in this project. The
> lazy parsing is really just a side-effect of the level of
> detail approach, but it promise to be very useful
> when doing global refactoring.
[AB::]
I definitly will take the time to look more closely on your ideas, since they sound very interessting.
> The current approach I have for something like a
> rename class is basically a 'grep' done on all the
> blanked sources, followed by an analysis of the
> part of the sources were the class name occurs to
> see if it is really the class name.
[AB::]
It's amazing, but if it works -- any fast algorithm will do !!
Now it's time for me to check the wikis :)
-- Andre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> [AB::]
> I also read this about the CVS not able to delete modules, just need to erase
> the files in the root directory (which is of cause only possible from sf-people).
> What about putting a file "depricated.txt" or "not-used-anymore.txt" in the
> root directories of these modules ?
We could also delete all files. When checking-out with the 'prune empty directory', the empty module would not appears.
> [AB::]
> I started going through this, and found the idea of ast node mutation very
> interesting - so this is just a handwritten parser ?
Yes. At a given level of detail parsing is fairly simple. Though we may want to use some generator if we ever decide to parse for expression (though, there is no need at the current time).
> [AB::]
> I'm sure some feedback will arise as soon as I'm looking more at the code. At
> the moment I'm still on the 100 mail-list articles :-) ... just not to ask again
> questions that have been answered allready ...
Please do ask (on the ML). This will help identify new comers FAQ.
> > 4) Let's not. The ToDo page on the wiki and the
> > mailing list provide much more flexibility.
>
> [AB::]
> Ok, I don't known about the features of the TODO implementation of SF. ... I
> was just wondering why this list is empty ... maybe add some hint in it, where
> to find the real to-do-list.
A lot of features provided by SF are not so practical to use (like the 20 characters limits for a bug subject :-( ).
> [AB::]
> I see, I also have to look at the wiki more closely -- by the way, what was
> this data loss of the wiki's ??
All sourceforge projects had their world writable htdocs files deleted last week. Because Usemod wiki store the page content in such files, they were deleted. There was no real loss though (I managed to find copy of the lost page in my web browser cache). We're in the process of making regular backup for sensible datas.
> ... Is it possible to store the pages somewhere in the project, just that we
> can check out these also as some kind of documentation ?
The only way I see of achieving that is to do an html mirror of the wiki pages.
Baptiste.
> -- Andre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for your detailed and valid criticism. I agree with the points you make. I myself have problems sometimes understanding all the intricacies of the project.
1) I'm not sure about the modules in the dsw files. As far as subdirectories go, rftaparser contains the more basic functions for parsing; rfta contains more refactoring-specific stuff.
3) good point.
4,5) We will use the task list since now we have more than 2 developers:) Baptiste and I never wrote it down, but I understand the tasks at hand as follows (not parallel):
a) make the RenameTemp refactoring run;
b) clean up the code;
c) tackle other method-wide refactorings (Split temp, inline temp, reduce scope etc.), possibly in parallel.
So long,
Sven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just impressed by the idea developing a refactoring tool I wrote down a list of refactoring issues that might be intresting to be discussed.
It would be usefull to think about the operations and figure out requirements for the refactoring tool. In my opinion it would be a good idea to build up a structured document on this discussion. just write down all ideas and decisions, as well as the requirements that follow out of this.
Just the list as an overview how this document can look like:
(6 operation types)
Rename Operations
Move Operations
Extraction Operations
Generation Operations
Interface Changes
Commenting Operations
Under these operations types you can see differentiations for the symbols in c++:
- namespaces
- modules (files)
- class
- structs
- variables
- functions/members
e.g. Generation --- generate getter/setter
e.g. Extraction --- build an abstract interface class
e.g. Commenting --- build doxygen/javadoc style comment framework for function headers.
If all of you are ok with this, I would just start to create the document and check it in to our documentation.
What about the text format - plain text is not good because links/index & a table of contents would be usefull.
-- andre baresel
Hi Andre,
Thanks for your ideas. One thing though. Have you subscribed to the mailing list? I think that some of the ideas that you are talking about are being discussed there. Check the archives, and feel free to post more of your thoughts there.
Cheers
John
Welcome Andre.
Sven has set up a wiki for this. There is a link to it on our home page (http://cpptool.sourceforge.net/). Though it seems there access write were not set correctly when it was restored (you can not edit page). I look into this this evening (directories under htdocs/wiki needs to be world writable).
I have already added a page discussing a few refactorings.
Baptiste.
Thx, i was trying these pages, but than i read about the problem with it -- i expected something like this .... thx !
-- andre
You should be able to access the wiki now.
Feel free to add pages (a NewComer page with all the question you may have would be nice).
Baptiste.
btw) Haven't you got any fears loosing the data again ? maybe the most important design decisions should be added in the "Docs" folder ? Just an idea ---
-- Andre
just found "RefactoringToolArticle" in the rfta module.
Which is quite useful to understand the ideas of the project.
Just some things for Users that come in the project:
1) - it's hard to understand the module structure
(just to make this clear to me: "rfta" is the applic. that tries to implement the refactoring algorithms ?)
2) - it's hard to get some overview documents on the whole project -- the doc-folder of the rfta module gave me a good start !
3) - it would be nice to have a short description on how interessted developers can start with the project sources... Maybe this is solved with point 1) better module structure.
4) - what about the use of the task list just in case more than just two developers are involved.
5) - what about writing down a list of the parallel projects which can be interesting for looking at (I saw these hints from 24.1.2002 somewhere in the forum) ... this would be usefull for new developers
Not just critisism:
- I was impressed by the CppUnit approach which directly starts the tests after compilation ... great !!
- I really see this project has some great ideas (e.g. lazy parsing) ... because of the big amount of work, we need to make these ideas popular, so don't hide them in the application doc folder !
Thanks for your comment.
1) As far as I understand, the CppRefactory and cpptool module in the CVS repository were previous attempt which were aborted.
Concerning the rfta module structure.
* src/rftaparser is the parser library. It takes some text and produce an AST. Only statements are parsed at the current time.
* src/astdump is an application using rftaparser. It takes a line range and dump the AST in HTML. Just run bin/test.bat for a demo.
* src/rfta is the AST analysis, refactoring and source modification library. It implements the RenameTempRefactoring and provide the TextDocument abstraction to manipulate sources.
2) I'll add a doc describing the content of the doc/ directory.
3) The tests are a good start. rftaparser is mainly a collection of mini-parser. rfta is a bit of a mess at the current time. Interresting test would be RenameTempRefactoringTest, TransformListTest, ScopeGeneratorTest and ScopeHolderTest. I'll try to continue the explanation about the parser on the wiki. More feedback on what need to be explained would be welcome.
4) Let's not. The ToDo page on the wiki and the mailing list provide much more flexibility.
5) Yes. I already started collecting a few links. I'll add a 'Resources' wiki page. There is also a few interesting articles...
I've updated the ToDo page on the wiki and provided a more detailed list of tasks. Some task are of course permanent (e.g. clean up the code ;-) ).
Concerning exposure of the lazy parsing idea, I'm in the process of writing a small document describing the approach used in this project. The lazy parsing is really just a side-effect of the level of detail approach, but it promise to be very useful when doing global refactoring.
The current approach I have for something like a rename class is basically a 'grep' done on all the blanked sources, followed by an analysis of the part of the sources were the class name occurs to see if it is really the class name.
Baptiste.
> 1) As far as I understand, the CppRefactory and
> cpptool module in the CVS repository were
> previous attempt which were aborted.
[AB::]
I also read this about the CVS not able to delete modules, just need to erase the files in the root directory (which is of cause only possible from sf-people). What about putting a file "depricated.txt" or "not-used-anymore.txt" in the root directories of these modules ?
> Concerning the rfta module structure.
> * src/rftaparser is the parser library. It takes some > text and produce an AST. Only statements are
> parsed at the current time.
[AB::]
I started going through this, and found the idea of ast node mutation very interesting - so this is just a handwritten parser ?
> * src/astdump is an application using rftaparser. It > takes a line range and dump the AST in HTML.
> Just run bin/test.bat for a demo.
[AB::]
works fine, I played arround with it allready.
> * src/rfta is the AST analysis, refactoring and
> source modification library. It implements the
> RenameTempRefactoring and provide the
> TextDocument abstraction to manipulate sources.
[AB::]
ok, I have to check this.
> 2) I'll add a doc describing the content of the doc/
> directory.
[AB::]
this seem not to be a high level priority since there're not much files, the problem was only to understand that this directory is important ;-)
> 3) The tests are a good start. rftaparser is mainly a > collection of mini-parser. rfta is a bit of a mess at
> the current time. Interresting test would be
> RenameTempRefactoringTest, TransformListTest,
> ScopeGeneratorTest and ScopeHolderTest. I'll try
> to continue the explanation about the parser on the
> wiki. More feedback on what need to be explained > would be welcome.
[AB::]
I'm sure some feedback will arise as soon as I'm looking more at the code. At the moment I'm still on the 100 mail-list articles :-) ... just not to ask again questions that have been answered allready ...
> 4) Let's not. The ToDo page on the wiki and the
> mailing list provide much more flexibility.
[AB::]
Ok, I don't known about the features of the TODO implementation of SF. ... I was just wondering why this list is empty ... maybe add some hint in it, where to find the real to-do-list.
> 5) Yes. I already started collecting a few links. I'll
> add a 'Resources' wiki page. There is also a few
> interesting articles...
[AB::]
I see, I also have to look at the wiki more closely -- by the way, what was this data loss of the wiki's ??
... Is it possible to store the pages somewhere in the project, just that we can check out these also as some kind of documentation ?
> I've updated the ToDo page on the wiki and provided
> a more detailed list of tasks. Some task are of
> course permanent (e.g. clean up the code ;-) ).
[AB::]
I known this from my developer team already ;-)
> Concerning exposure of the lazy parsing idea, I'm
> in the process of writing a small document
> describing the approach used in this project. The
> lazy parsing is really just a side-effect of the level of
> detail approach, but it promise to be very useful
> when doing global refactoring.
[AB::]
I definitly will take the time to look more closely on your ideas, since they sound very interessting.
> The current approach I have for something like a
> rename class is basically a 'grep' done on all the
> blanked sources, followed by an analysis of the
> part of the sources were the class name occurs to
> see if it is really the class name.
[AB::]
It's amazing, but if it works -- any fast algorithm will do !!
Now it's time for me to check the wikis :)
-- Andre
> [AB::]
> I also read this about the CVS not able to delete modules, just need to erase
> the files in the root directory (which is of cause only possible from sf-people).
> What about putting a file "depricated.txt" or "not-used-anymore.txt" in the
> root directories of these modules ?
We could also delete all files. When checking-out with the 'prune empty directory', the empty module would not appears.
> [AB::]
> I started going through this, and found the idea of ast node mutation very
> interesting - so this is just a handwritten parser ?
Yes. At a given level of detail parsing is fairly simple. Though we may want to use some generator if we ever decide to parse for expression (though, there is no need at the current time).
> [AB::]
> I'm sure some feedback will arise as soon as I'm looking more at the code. At
> the moment I'm still on the 100 mail-list articles :-) ... just not to ask again
> questions that have been answered allready ...
Please do ask (on the ML). This will help identify new comers FAQ.
> > 4) Let's not. The ToDo page on the wiki and the
> > mailing list provide much more flexibility.
>
> [AB::]
> Ok, I don't known about the features of the TODO implementation of SF. ... I
> was just wondering why this list is empty ... maybe add some hint in it, where
> to find the real to-do-list.
A lot of features provided by SF are not so practical to use (like the 20 characters limits for a bug subject :-( ).
> [AB::]
> I see, I also have to look at the wiki more closely -- by the way, what was
> this data loss of the wiki's ??
All sourceforge projects had their world writable htdocs files deleted last week. Because Usemod wiki store the page content in such files, they were deleted. There was no real loss though (I managed to find copy of the lost page in my web browser cache). We're in the process of making regular backup for sensible datas.
> ... Is it possible to store the pages somewhere in the project, just that we
> can check out these also as some kind of documentation ?
The only way I see of achieving that is to do an html mirror of the wiki pages.
Baptiste.
> -- Andre
Andre,
thanks for your detailed and valid criticism. I agree with the points you make. I myself have problems sometimes understanding all the intricacies of the project.
1) I'm not sure about the modules in the dsw files. As far as subdirectories go, rftaparser contains the more basic functions for parsing; rfta contains more refactoring-specific stuff.
3) good point.
4,5) We will use the task list since now we have more than 2 developers:) Baptiste and I never wrote it down, but I understand the tasks at hand as follows (not parallel):
a) make the RenameTemp refactoring run;
b) clean up the code;
c) tackle other method-wide refactorings (Split temp, inline temp, reduce scope etc.), possibly in parallel.
So long,
Sven.