This document occasionally uses terms that appear in capital letters.
When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY"
appear capitalized, they are being used to indicate particular
requirements of this specification. A discussion of the meanings of
these terms appears in RFC 2119
For those who want to rewrite CodeCompletion using an existing C++ parser, here's what we should do:
(These guidelines are subject to change without notice)
- It SHOULD be designed around the class browser: Classes, Functions, Variables, Enums, Preprocessor.
- The code completion plugin MUST hold an in-memory structure (maps, arrays, whatever is necessary) to contain all the tokens. For example, a class would include member variables, methods, and the methods would include the local variables.
- This structure MUST be independent from the GUI. It MUST be a container. All code MUST be done by another class, but it MAY include saving, reading / writing from cache, and necessary functions.
- There SHOULD be a structure per development language in the project. It's no use mixing C++ and Perl tokens, it would only create confusion.
- The codecompletion plugin SHOULD have modules for different languages, these modules would consist of thread-safe functions to add the tokens into the main structure.
- The ParserThread (this part we'll keep, but with the necessary adaptations) will call the modules to parse the different files.
- For classes, use of STL classes (like vector and map) is RECOMMENDED, but you MAY NOT use std::string. You MUST use wxString instead. Use of only the std::string compatibility functions is RECOMMENDED.
(Contributions to these ideas are welcome)