Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Languages Tools Factorization"
(→Active Language Development Tools) |
(→Existing common features) |
||
| Line 27: | Line 27: | ||
* [http://objectteams.org/distrib/otdt.html Object Teams] (JVM) | * [http://objectteams.org/distrib/otdt.html Object Teams] (JVM) | ||
| − | = | + | = Common features = |
== Indexing == | == Indexing == | ||
| − | + | Indexing the code structure to make it efficient to search for types/members. There are two components of this feature: | |
| − | * | + | * Creating indexes: This operation visits a document (or all documents in a project) and extracts relevant keys from inside of them, placing them in a datastore. |
| − | + | * Searching indexes: This operation searches the datastore for documents containing a given key. The result of this operation is a set of documents known to contain the given key. These documents are now suitable for a fine-grained search. | |
| − | * | + | * The datastore itself should be language agnostic. Although, some of the keys placed in the datastore may not be relevant to all languages. |
| − | * | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | === Known implementations === | ||
| − | + | JDT implements a datastore. AJDT and Groovy-Eclipse (and potentially others) implement source code visitors that populate the datastore with language-specific keys. To be more precise, the keys added to the datastore have Java semantics even when they do not represent Java artifacts (eg- pointcuts in AspectJ are stored as method declaration keys). This is problematic. | |
| − | + | == Fine-grained search == | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Searches a single document to find a precise location of a semantically rich search pattern. The document is typically a file, archive entry, or a module written in any programming language supported by the current Eclipse IDE. | |
| − | + | === Known implementations === | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | JDT, AJDT, Groovy-Eclipse (and potentially others). | ||
| − | == ... == | + | == Refactoring == |
| + | |||
| + | Idea is to provide cross-language refactoring support. For example, being able to rename semantically identical references and declarations in both C and JavaScript. | ||
| + | |||
| + | == Navigation == | ||
| + | |||
| + | Idea is to provide a seamless way to navigate to the declaration of a reference across language boundaries. | ||
| + | |||
| + | == Model == | ||
| − | + | Describes an abstract structure of a project so that individual elements can be identified, located, and manipulated. Possibly a prerequisite for refactoring and navigation. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
= Potential new features = | = Potential new features = | ||
Revision as of 19:49, 27 August 2013
Contents
Goal
Eclipse is the host of various programming languages tools (JDT, CDT, JSDT/VJET, AJDT, PDT... at Eclipse.org; Ceylon-IDE, Groovy-Eclipse, Scala-IDE, Counterclockwise... outside of Eclipse.org). Most of these tools have been sharing the same features but not necessary the same code because of the lack of factorization on this topic.
The goal is to find out which pieces are implemented by most Language Development Tool, and to implement them in a generic/universal way as part of a LTK-like project or component (or LTK itself). Then, it would be easier to write Tools for new languages by re-using the available bundles, and more mature projects could move towards this new bundles in order to benefit from factorization.
Useful Links/Discussions
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=36939
- http://www.eclipse.org/org/langsymp/ (?)
- http://dev.eclipse.org/mhonarc/lists/ide-dev/msg00023.html (2013)
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=415563 (2013)
Existing Language Development Tools
This is not meant to be an exhaustive list of all LDTs. It is meant to identify which LDTs are under active development and can serve as examples of the kinds of languages and features we want to support:
- JDT (JVM)
- JSDT
- AJDT (JVM)
- CDT
- PDT
- Groovy-Eclipse (JVM)
- CeylonIDE (JVM)
- Scala-IDE (JVM)
- Counterclockwise (JVM)
- Object Teams (JVM)
Common features
Indexing
Indexing the code structure to make it efficient to search for types/members. There are two components of this feature:
- Creating indexes: This operation visits a document (or all documents in a project) and extracts relevant keys from inside of them, placing them in a datastore.
- Searching indexes: This operation searches the datastore for documents containing a given key. The result of this operation is a set of documents known to contain the given key. These documents are now suitable for a fine-grained search.
- The datastore itself should be language agnostic. Although, some of the keys placed in the datastore may not be relevant to all languages.
Known implementations
JDT implements a datastore. AJDT and Groovy-Eclipse (and potentially others) implement source code visitors that populate the datastore with language-specific keys. To be more precise, the keys added to the datastore have Java semantics even when they do not represent Java artifacts (eg- pointcuts in AspectJ are stored as method declaration keys). This is problematic.
Fine-grained search
Searches a single document to find a precise location of a semantically rich search pattern. The document is typically a file, archive entry, or a module written in any programming language supported by the current Eclipse IDE.
Known implementations
JDT, AJDT, Groovy-Eclipse (and potentially others).
Refactoring
Idea is to provide cross-language refactoring support. For example, being able to rename semantically identical references and declarations in both C and JavaScript.
Idea is to provide a seamless way to navigate to the declaration of a reference across language boundaries.
Model
Describes an abstract structure of a project so that individual elements can be identified, located, and manipulated. Possibly a prerequisite for refactoring and navigation.
Potential new features
Cross-languages search
- Purpose Polyglot development is becoming mainstream, it would be interesting to develop the tools to handle it easily. For example, developing with Qt can mix JavaScript and C++