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

New code completion plugin w/ refactoring

<< < (3/9) > >>

artoj:
So we could have something like this:

In core (build in Code::Blocks itself) it's the Language manager. This language manager will load/unload language libraries. Language manager will also handle file extensions and syntax lighting (= all language properties in one place). The language manager will define set of properties that every language must handle, e.g. these could be functions and members (we need these to build the cache).

The language library would handle all implementation, the language parser, refactoring, styles and parser. In the most optimal case extending C::B to use new language would only require dropping one library to the plugins path or separate languages path.

---

The work that this would require would be massive, period. I'm not saying this cannot be done and I agree that currently the language/parser/syntax lighting/file extensions system is a mess. I think that some vital functions should be in core, the cache would be good example because practically every language needs it. One could argue that there's no need to build anything to the core if we make plugin which uses plugins, great. :lol:

It's great to see new ideas, keep them coming 8)

Pete:
May be caсhe can be implemented as a service. If cache implementation for c++ will provide all functionality needed for other languages, i can use cache service whitout integrating its source code in my language library.

sethjackson:
I think that is good. One thing though. Keep the styling done through XML.  :)

artoj:

--- Quote from: Pete on February 14, 2006, 01:24:19 pm ---May be caсhe can be implemented as a service. If cache implementation for c++ will provide all functionality needed for other languages, i can use cache service whitout integrating its source code in my language library.

--- End quote ---

Yup, that could be possible. This could lead to "plugin hell" though, separate plugins relay on different versions of each other. The interface that the cache would be used would have to be so good that it wouldn't require changes often. The PluginManager included currently in Code::Blocks allows us to call different plugins. I don't know about PluginManager's thread safety (pretty sure it isn't), the cache system must be thread safe because it will be called all over the place.

Another good idea for the separate cache would be the class treeview system / function & class listboxes in separate plugins BUT because we must assume that we don't know anything about the language we are using can causes several problems: how are we going to layout the tree/whatever if don't know if the language has namespaces or classes or is the language only procedural. We could however use namespaces and classes in every language but put something like "(global)" or something like that to the name of the class/namespace if the language doesn't support classes/namespaces.

In the original idea I was going to add some sort of meta block to the cache and every language could add some important data to it for further usage. If language "x" supports some new function type "y" it could mark those functions with "y" in the meta block and then later use that info for example showing user in the UI/class treeview that these functions are "y" type. I'm not sure if I'm going to trash this idea or not. If this idea will be implemented it would mean that the UI usage and language specification must be very close to each other. We could again however somehow query the language plugin how we should layout this data we have.

It could work. 8)

Game_Ender:
The only thing you can do with the current level of information the code-completion provides is code complete.  You need a full abstract syntax tree of a language to create good UML diagrams and do reliable refactoring.  That AST will be at the very least langauge specific and even parser specific.  The current code completion plugin is general enough for any language.  Non OO languages can just have everything at global scope for now.

I don't think you can create a general AST that a UML/Refactoring program can rely on.  The UML/Refactoring program is going to have to be dependent on the langauge module (parser and AST).  Like you said it will probably be possible to create a general thread safe cache system that can store any kind of data you want.

Maybe if I have the time I will whip a UML diagram, in the end there should definetly be one made before the codeing starts.

Navigation

[0] Message Index

[#] Next page

[*] Previous page