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.
Yup, the refactoring part is pretty tricky. With code completion we can just scan the function names and put them to cache, but for refactoring we need every functions local data aswell. I haven't tought the details yet because I want to have a basic layout of the plugin first and then build more specific features on top of it.
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).
Correct, that's why the refactoring engine worked under the specific language (seen in the first message), so it can use its specification.
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.
That's the plan, but I don't know if that's possible (store any kind of data), we shall see. Code completion for brainf*ck would be quite cool though. :lol:
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.
Yes, there will definitely be UML diagrams of this plugin. The whole coding process is not important issue right now. The most important thing now is to create a basic layout of the plugin and then specialize it. This planning phase is the most important thing in order this plugin to be successful. Like I said, when we have the full documentation this plugin is 50 % ready.
That would certainly add some flexibility and ease-of-use to it -- but is it the best way to do it? I just know someone would come along and implement the entire language in the meta block, or do something else stupid with it.
Yeah, I see your point. We could however expose the whole cache system for the language plugin. So it could itself create the database tables and use any information it wants. This would allow us to extend the cache system any language we want. This would put more stress to the language plugin developer though.
I think we shouldn't look too hard for common structure between languages when it isn't there. How, for instance, would you design a cache system that could store C++ abstract syntax trees, F77 structure models, CSS structures, and Bison grammars? I haven't tried, but there might end up being so many differences that the best common ground we find would be reading and writing some sort of "nodes" whose structures depend on the language.
Yeah, the language would itself define the structure of its database tables. These values (structures) could be asked from the language plugin for example if some new UI/whatever plugin needs them.
In the end, I don't know exactly what I'm saying, except "do it right". The interfaces you design should be, if not simple, then hopefully intuitive.
You raised some important topics, that's good. It's important remember that this is a community project and it's very important that the community will provide feedback and new ideas, we're all in this together. Only as a community we can do this right.
Arto
