Yannis and I have talked about creating a new code completion plugin with support for refactoring, it will be a full rewrite. If I'm lucky I will get a summer job in this project, that's about 3 months working full-time with C::B. Hopefully after summer we have something done (I'm not promising anything though).
I'm currently working with the most important part of the plugin, the planning. I know that there are very talented programmers/designers in these forums so I would like to hear your opinions about the plugin when we have something to show you. I want the planning phase to be as open as possible, like rickg22 did with the current plugin.
The initial plan is to create the plugin using eranif's ideas: CTags and SQLite. I've made very, very, very simple layout of the plugin which I had in mind:
"The plugin"
|
Languages
/ | \
C/C++ Python Java
| | |
P&R E P&R E P&R E
--------------------------------
Common Parser | Common Refactor
--------------------------------
So what these all mean? At the top we have the plugin which will implement all our features. The plugin defines a set of languages. These can be anything. I'm not saying C::B should handle Python or Java code, it's just an example (we'll focus the C/C++ part). Each language defines its own Parser & Refactor Engine (P&R E) which will called when needed. These "engines" are subclasses of Common Parser and Common Refactor. Common Parser and Common Refactor are just abstract classes which will define what features parser and refactor have.
For example, in Common Refactor we could say:
bool ExtractMethod(wxString[] codeblock);
or something like that. Now, each language defines this ExtractMethod refactoring scheme anyway it wants. This was designed (well, though, because the design phase is just beginning) this way because we don't know what languages we will support in the future.
Because there is about 70 different refactoring schemes (some of them are very complicated), we won't be creating them all at once. I'm thinking that ExtractMethod and RenameMethod are the two that we want to implement first.
We want to be able to extend the Common Parser too. I'm thinking that the Common Parser could just be a wrapper to CTags, if we want to change CTags to a different parsing system, so be it, the methods in the Common Parser remain the same.
I haven't thought the SQL system much yet. I don't know should we create another wrapper to the cache and use SQLite under it. This could be a good decision because, again, we don't know what happens in future.
Another thing I thought this morning was how to efficiently use the the cache between restarts. We want to save the database to disk, but what about files that have changed since we last used the database. I was thinking some extremely simple (and fast) checksum system that we could use to check if the files are changed.
So what happens now?
You can just sit back and relax.
I don't think I will be presenting anything major in this month. When the design phase is over I let you guys know. After we got the full documentation this plugin is 50 % complete.
And please don't ask when we are going to release this plugin, honestly, we don't know.
rickg22, thank you for your hard work with the current plugin.
- Arto
