[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 66683] Implement Code refactoring
From:       "Michael L." <wisd00m () gmx ! net>
Date:       2006-01-17 16:14:55
Message-ID: 20060117161455.11973.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=66683         




------- Additional Comments From wisd00m gmx net  2006-01-17 17:14 -------
Hi,
I did play quite a bit with this idea and I my thoughts so far have lead to the \
following  conclusions, feel free to comment :-)

a) it would be crucial to really make this a highly portable library that does not \
have any  unreasonable dependencies, thus it must really not depend on something like \
KDE/KDevelop (probably not even QT!), rather it should provide an open interface \
(possibly providing a network'ed  IPC interface?), so that it can be used by/with any \
(IDE) project on any platform, this would  also ensure that there is a huge group of \
potential contributors. A network'ed IPC interface  would also add the possibility to \
introduce a server/client architecture very soon, with all  its benefits.

b) one should really not attempt to write a parser for something as complex as C++, \
rather the key  to success would be to have an open source compiler such as \
gcc/openc++ provide its COMPLETE parse  tree as some sort of machine-readable \
(XML/RDF) output (there are already compilers (or patches  for gcc) to do exactly \
this (will post references later!))

c) such XML/RDF output should then be used to populate a SQL database for each \
unit/source file,  so that a cross-referencing database with symbols (namespaces, \
classes/structs,functions etc.) can  be created. Then, it would mainly come down to \
knowing some basic SQL in order to be able to  do actual refactoring(=SQL queries!). 
Also, we should concentrate on not using any specific SQL database, rather there are \
free SQL DB  abstraction layers/libraries, that will support a whole variety of \
backends/databases (PostGres, mySQL,  mSQL,BerkeleyDB, SQLite).

d) it would probably be preferable to develop some sort of "meta"-refactoring \
language (possibly, SQL oriented) that would allow people to define macros (low- and \
high-level ones) for refactoring, for example: "RENAME FUNC void doStuff(void) IN \
                FILE src/main.cxx to doStuff2" could automatically comprise:
- select rows for corresponding source file and scope/namespace
- locate/find symbols for function doStuff
- rename function in prototype & declaration
- determine callers (look up cross-references via SQL query)
- optionally rename the callers accordingly
during such an operation, the affected source files would be 'locked', so that other \
refactorings  do not interfere with them. Users would then be offered the possibility \
to flush the changes from  the DB to the corresponding source files.

e) ultimately, it would probably not be desirable to hardcode such things in C/C++ \
for each refactoring action individually, rather a good approach might be to really \
embed some scripting  interpreter such as perl into the library, so that each \
refactoring action/macro can be implemented  using perl, that way the library would \
become highly maintainable and extendable. Eventually, this approach would also open \
up the possibility to easily add support for additional  programming languages to \
such a library in the future.

f) finally, it might become desirable to design an architecture with a high level of \
concurrency  in mind (threaded design), so that the library can later on be used in a \
non-blocking mode  (whenever possible), as well as support SMP platforms where \
applicable. Using CORBA for this goal, would ultimately also satisfy the requirements \
for a network'ed IPC interface.

g) as such a library would ultimately be modifying the source code on the file \
system, it would  initially probably be a good requirement to have the lib only work \
with source code that is  being managed using a source management system such as \
CVS/SVN, that way we would not necessarily  have to take care of the whole "UNDO" \
complexities when things are screwed up, and we would make sure that every step could \
be easily reverted quickly.

more to come soon... :-)


[prev in list] [next in list] [prev in thread] [next in thread]