Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

New code completion plugin w/ refactoring

<< < (2/9) > >>

TDragon:
1. Replaceable and subclassable interfaces are a Good Thing™. That way it'll require minimal redesign on my end and no redesign on the main plugin when I unveil my hyper-advanced C/C++ parser. ;)

2. Make sure you provide functionality to let the parsers do structure introspection too. C++ in particular is a highly context-relative language, so it needs to be able to look back at what it's already parsed in order to understand what it's currently parsing.

3. The saying "Make it work. Make it fast. Make it right. Pick any two" doesn't apply to code completion / visual assist software. It needs to work quickly and correctly, or it'll be a turn-off (both literally and figuratively).

More as I think of them,
Cheers,
Good luck,
JohnE / TDM

Game_Ender:
I love the plugable parser model, I am sure everyone has a pet parser they would love to see placed in the codecompeletion pluggin so we can finally get some template and typedef recognition.  I have my hat tossed in with the Elsa parser, especially if you want to do refactoring.

One thing your model does not address is threading.  This needs to thought of from the beginning, because it has a very flaky feel in the current plugin.  There is no offense meant to the authors, it just that the threading code is not very robust. If we work out the specific thread design we want to use (worker thread(s), a new thread per parsing job etc) now it will be easy to design the interactions of the components to place nice in that system. 

I also don't know if using something like boost.threads would help or not, but I would consider heavier use of helper libraries like boost.  IMHO the wxWidgets "support" classes should probably be avoided if there they are already in boost or the stl, but that is another issue all together.

rickg22:
Suggestion, make the parsing per-workspace and not per-project, otherwise we'll still suffer the memory issues...

Pete:
I'd like to propose the more separted model

--- Code: (dos) ---------------------------------------
internal source code model
-----------------------------------------------------------------------------------
an interface for manipulations with internal model
-----------------------------------------------------------------------------------
/\               |                         |    /\            /\   |
|                |                        \/    |             |   \/
------      ------------------     -------------------     ----------
parser      source code styler     UML representation      refactoring
------     -------------------     -------------------      plugin
|                 |                                        ----------- 
|                \/
-------------------------------
source code listing,
edit window or something similar
-------------------------------

--- End code ---
This way parsing and refactoring will be separated from internal source code representation, common refactor will be obsolete.
Another idea is a script wrapper for manipulations with source code model. I think it's more easy to write for code analizing and refactoring, than writing a c++ plugin or external application with another source parsing.

PS sorry for my poor english :(

takeshimiya:
Agreed, there should be one C++ parser for all plugins, no more.

Navigation

[0] Message Index

[#] Next page

[*] Previous page