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 "Xtext/planning 0.8.0"
< Xtext
(APT, some explanation) |
|||
| Line 6: | Line 6: | ||
We need to improve our build infrastructure as well as the general workspace setup. | We need to improve our build infrastructure as well as the general workspace setup. | ||
It would be nice to use a target platform. | It would be nice to use a target platform. | ||
| + | |||
| + | == Refactoring == | ||
| + | |||
| + | * Review the Scoping API. We should provide a sort of IScopeExtension with methods like #getElement(String):IScopedElement and #getElement(EObject):IScopedElement. This allows more sophisticated implementations of the API. | ||
| + | * Review the Highlighting API: Merge the *Configuration-Interfaces. | ||
| + | * Review the implementation of the Classpath URI. Try to find a solution, that allows this kind of URI even in other ResourceSet implementations. | ||
=== Xtext Grammar === | === Xtext Grammar === | ||
The linking of the grammar should be reviewed and updated to reflect the latest changes in the API and to be a better example on how to use the different available APIs. Furthermore there are still some possible links, that are currently plain strings. | The linking of the grammar should be reviewed and updated to reflect the latest changes in the API and to be a better example on how to use the different available APIs. Furthermore there are still some possible links, that are currently plain strings. | ||
| + | |||
| + | === Project structure === | ||
| + | |||
| + | Move as much as possible from org.eclipse.xtext into org.eclipse.xtext.xtext (similar to org.eclipse.xtext.xtext.ui). Merge org.eclipse.xtext.ui.core and org.eclipse.xtext.ui.common into org.eclipse.xtext.ui as the difference between both plugins is somewhat indistinct. | ||
== Project Management == | == Project Management == | ||
We should come up with a minimal set of style guidelines and conventions to minimize the necessary effort to merge changes and understand code. | We should come up with a minimal set of style guidelines and conventions to minimize the necessary effort to merge changes and understand code. | ||
| − | Ideally, we should try to stick to Eclipse defaults as much as possible, as this minimized configuration efforts. | + | Ideally, we should try to stick to Eclipse defaults as much as possible, as this minimized configuration efforts. |
| + | We should use project specific settings wherever applicable to minimize the risk of the I-forgot-to-import-some-settings-scenario. This includes encoding, code style, save participants, compiler warnings, organize imports and pde settings. | ||
== Third party libs == | == Third party libs == | ||
| Line 21: | Line 32: | ||
* Google Collections 1.0: We currently use v 0.8 alpha. The API has changed significantly and we should update to 1.0. | * Google Collections 1.0: We currently use v 0.8 alpha. The API has changed significantly and we should update to 1.0. | ||
* ANTLR 3.1.x: A bunch of fixes and new features has been incorporated into ANTLR 3.1. Especially the support for grammar imports seems to be interesting. | * ANTLR 3.1.x: A bunch of fixes and new features has been incorporated into ANTLR 3.1. Especially the support for grammar imports seems to be interesting. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== New Features == | == New Features == | ||
| Line 39: | Line 44: | ||
** Introduce an official API that allows to define default values of the semantic model. | ** Introduce an official API that allows to define default values of the semantic model. | ||
* UI Features | * UI Features | ||
| − | ** AutoEdit: This would greatly improve the user experience and help to minimize the on-type-changes in the semantic model. | + | ** AutoEdit: This would greatly improve the user experience and help to minimize the on-type-changes in the semantic model. Without autoedit, the model becomes totally corrupt when the user tries to write a STRING literal, because everything behind the opening quotes will be consumend as a STRING. In almost any case this is not the intention of the user. Autoedit would insert a matching closing quote after to opening quote and the model will remain much more stable. Btw: Autoedit is not the right term here. JDT implemented this with a VerifyKeyListener (see org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.BracketInserter). |
** Quick fixes, QuickAssist-API | ** Quick fixes, QuickAssist-API | ||
** Advanced Navigation / Hyperlinking API: Find References, allow to define references by convention, etc. | ** Advanced Navigation / Hyperlinking API: Find References, allow to define references by convention, etc. | ||
| Line 46: | Line 51: | ||
** View points in the Outline | ** View points in the Outline | ||
** Hook for Tooltips: users might want to display additional information when the mouse hovers over a reference, e.g. documentation. We should provide a hook for feeding this information. | ** Hook for Tooltips: users might want to display additional information when the mouse hovers over a reference, e.g. documentation. We should provide a hook for feeding this information. | ||
| − | ** Enhance "New Xtext Project" wizard: let user choose among various | + | ** Enhance "New Xtext Project" wizard: let user choose among various examples (see PDE New Project wizard to see this in action) |
** Add "New DSL Project" wizard to generated DSL, supply hooks for customization | ** Add "New DSL Project" wizard to generated DSL, supply hooks for customization | ||
* Xtext Grammar | * Xtext Grammar | ||
| Line 56: | Line 61: | ||
* Xtext Grammar Editor | * Xtext Grammar Editor | ||
** Tabbed Editor that visualizes the generated EPackages on other tabs. Maybe we should use other views for this aspect. | ** Tabbed Editor that visualizes the generated EPackages on other tabs. Maybe we should use other views for this aspect. | ||
| − | ** Syntax diagram view (see http://weblogs.java.net/blog/cayhorstmann/archive/2006/07/railroad_diagra.html | + | ** Syntax diagram view (see http://weblogs.java.net/blog/cayhorstmann/archive/2006/07/railroad_diagra.html, http://en.wikipedia.org/wiki/Syntax_diagram and http://www.antlr.org/works/screenshots/ambiguouspath.jpg) |
** Provide more validation | ** Provide more validation | ||
** Provide more semantic highlighting | ** Provide more semantic highlighting | ||
| + | * PolymorphicDispatcher | ||
| + | ** Provider tool support for polymorphic dispatching. The Annotation Processing Tools (APT) allow an integration into the JDT and into Suns Java compiler. | ||
Revision as of 02:15, 7 July 2009
Here we collect what we want to do in the upcoming development (Helios) for Xtext.
Contents
Clean ups
Build infrastructure
We need to improve our build infrastructure as well as the general workspace setup. It would be nice to use a target platform.
Refactoring
- Review the Scoping API. We should provide a sort of IScopeExtension with methods like #getElement(String):IScopedElement and #getElement(EObject):IScopedElement. This allows more sophisticated implementations of the API.
- Review the Highlighting API: Merge the *Configuration-Interfaces.
- Review the implementation of the Classpath URI. Try to find a solution, that allows this kind of URI even in other ResourceSet implementations.
Xtext Grammar
The linking of the grammar should be reviewed and updated to reflect the latest changes in the API and to be a better example on how to use the different available APIs. Furthermore there are still some possible links, that are currently plain strings.
Project structure
Move as much as possible from org.eclipse.xtext into org.eclipse.xtext.xtext (similar to org.eclipse.xtext.xtext.ui). Merge org.eclipse.xtext.ui.core and org.eclipse.xtext.ui.common into org.eclipse.xtext.ui as the difference between both plugins is somewhat indistinct.
Project Management
We should come up with a minimal set of style guidelines and conventions to minimize the necessary effort to merge changes and understand code. Ideally, we should try to stick to Eclipse defaults as much as possible, as this minimized configuration efforts. We should use project specific settings wherever applicable to minimize the risk of the I-forgot-to-import-some-settings-scenario. This includes encoding, code style, save participants, compiler warnings, organize imports and pde settings.
Third party libs
Update the used libraries:
- Guice2: Multibinding support
- Google Collections 1.0: We currently use v 0.8 alpha. The API has changed significantly and we should update to 1.0.
- ANTLR 3.1.x: A bunch of fixes and new features has been incorporated into ANTLR 3.1. Especially the support for grammar imports seems to be interesting.
New Features
- Introduce DSLs for some of the stable viewpoints of Xtext.
- Migrate to upcoming EMF Index changes
- Query Builder
- API / SPI separation
- Runtime Features
- Formatting API that allows to define rules depending on the current state of your model.
- Allow tracing / impact analysis to implement partial linking, validation etc.
- Introduce an official API that allows to define default values of the semantic model.
- UI Features
- AutoEdit: This would greatly improve the user experience and help to minimize the on-type-changes in the semantic model. Without autoedit, the model becomes totally corrupt when the user tries to write a STRING literal, because everything behind the opening quotes will be consumend as a STRING. In almost any case this is not the intention of the user. Autoedit would insert a matching closing quote after to opening quote and the model will remain much more stable. Btw: Autoedit is not the right term here. JDT implemented this with a VerifyKeyListener (see org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.BracketInserter).
- Quick fixes, QuickAssist-API
- Advanced Navigation / Hyperlinking API: Find References, allow to define references by convention, etc.
- Highlighting: Allow to merge different highlighting styles that have been applied to the very same region of the model file.
- API that allows to define other views for the model in the Editor (comparable to viewpoints in the Outline)
- View points in the Outline
- Hook for Tooltips: users might want to display additional information when the mouse hovers over a reference, e.g. documentation. We should provide a hook for feeding this information.
- Enhance "New Xtext Project" wizard: let user choose among various examples (see PDE New Project wizard to see this in action)
- Add "New DSL Project" wizard to generated DSL, supply hooks for customization
- Xtext Grammar
- Terminal fragments: Reusable elements in terminal rules, that are not globally visible (see ANTLR Fragments)
- Aspects in production rules: Reuse different aspects of the grammar across various parser rules. One may think of infered EObjects that implement different interfaces such as Named, Documentable or FooContainer or BarReference. (You may call it a fragment).
- Allow a notation to call the super-definition of a overridden parser rule.
- Allow to define the default of an EEnum (even with an empty literal representation).
- Try to generate named opposite references for eContainer.
- Xtext Grammar Editor
- Tabbed Editor that visualizes the generated EPackages on other tabs. Maybe we should use other views for this aspect.
- Syntax diagram view (see http://weblogs.java.net/blog/cayhorstmann/archive/2006/07/railroad_diagra.html, http://en.wikipedia.org/wiki/Syntax_diagram and http://www.antlr.org/works/screenshots/ambiguouspath.jpg)
- Provide more validation
- Provide more semantic highlighting
- PolymorphicDispatcher
- Provider tool support for polymorphic dispatching. The Annotation Processing Tools (APT) allow an integration into the JDT and into Suns Java compiler.
