Author Topic: First attempt at redesign (Game Ender's idea)  (Read 8696 times)

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
First attempt at redesign (Game Ender's idea)
« on: December 21, 2005, 05:31:21 am »
Game Ender: I created this thread so we can start discussing your idea to redesign code completion. Feel free to post :)

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: First attempt at redesign (Game Ender's idea)
« Reply #1 on: January 01, 2006, 05:48:05 am »
First I have to say I like the new forum look.  I have been looking at two goals in a codecompletion redesign, a plugable parser module and exposing the parser through the SDK.  Having a plugable parser would mean you could load different parsers at run time to add support for additional languages.  This means third parties could implement a python parser, java parser, or ruby parser and just drop it in.  This combined with the greater flexibility that the compiler plugin redesign should bring will make it easier to add support for entierly different language to Codeblocks.

The other major goal is to make the parser more general and accessible through the SDK.  This would allow the easier design of plugins that have a closer relationship with the source.  Like a refactorer, a UML designer, or give wxSmith easier management of user created and generated code.  One way I have scene this done is the way Ogre does it with scene managers.  There is an abstract scene manager interface fulfilled at run time by pluggable scene managers.  The issue I am still working on, is it possible to come up with a general parser interface that makes provides enough functionality to be worthwhile or do need access to the AST in order to get any real work done.

Note: some of the above was probably said in the requirements for a new parser thread, I will give it a close look and throw some updates in here.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: First attempt at redesign (Game Ender's idea)
« Reply #2 on: January 04, 2006, 10:42:35 pm »
That seems an interesting idea. Right now i'm working on the optimization of the Class Browser creation. As I go on, i'll try to separate the parser into its own class.

It'll be like this:

parser -> Spawns: parserthread -> will link to: parser_module.

The parser module will parse a buffer according to certain rules, and return a Token. More or less like this:

Token* token = 0;
while(!testdestroy() && m_parsermodule->GetNextToken(token))
{
  (do stuff with token, insert it into the tree, etc.)
  token = 0;
}

And that's about it. This means the parser module will have to be a state machine, and return the token data. What do you think?