Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "VIATRA/DeveloperDocumentation/Viatra2.0Brainstorming"
(Created page with "== Viatra 2.0 Design Docs and Brainstorming, Fall 2017 == === Overview === Minimum dependencies * Java 8 * Eclipse Mars * Xtext 2.12 * Guava 21 * Eclipse Collections 9 Comp...") |
|||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | {{VIATRA}} | ||
== Viatra 2.0 Design Docs and Brainstorming, Fall 2017 == | == Viatra 2.0 Design Docs and Brainstorming, Fall 2017 == | ||
Line 55: | Line 56: | ||
** In case of surrogates, remove types from API | ** In case of surrogates, remove types from API | ||
** Can Matches also be Tuples, or at least backed by them? Try to reduce (persistent and transient) duplication. | ** Can Matches also be Tuples, or at least backed by them? Try to reduce (persistent and transient) duplication. | ||
+ | * Distributed processing extensions | ||
+ | ** ??? |
Latest revision as of 09:36, 28 March 2024
Contents
Viatra 2.0 Design Docs and Brainstorming, Fall 2017
Overview
Minimum dependencies
- Java 8
- Eclipse Mars
- Xtext 2.12
- Guava 21
- Eclipse Collections 9
Components to keep or graduate:
Main points to address
- Scoping and imports in VQL (breaking backward compatibility on query definitions)
- Minimum dependency updates (see above)
- Remove all deprecated API
- Consider using runtime exceptions instead of checked exceptions
- See list of issues in 2.0.0M1
Top priority until March 2018
- Runtime API breaks
- VQL2 language
Language design changes
- Add file-level element that can receive annotations
- Rethink public/private patterns
- Let runtime know what is important for `Release` performance
- Important for incremental engines: know what must be maintained, what can be flattened
- Compositional sources of base relations (scopes)
- Better support for non-EMF scopes
- Better support for user-supplied relations, magic sets, traceability, etc.
- Must be mixable as freely as possible
- Minor syntactic sugar
- graph-like mnemonic for unary and binary base relations
- neg {local pattern}
- neg BareType(notWrappedInHelperPattern)
Runtime design changes
- API debt
- Remove all deprecated API
- Consider using runtime exceptions instead of checked exceptions
- Compositional scopes to support associated language goal
- User-supplied relations
- VQ Engine owner shall be able to provide (through an easy API) the contents of custom relations that the query definitions can rely on
- API1 to provide custom relations that realize the relevant IQMC, IQRC methods, including index lookup and notifications
- API2 where index lookups are taken care of, contents and notifications are still provided by the user
- API3 where these relations are implemented e.g. as a set (with indexer lookups, notifications, etc.), the user can call manipulation operations
- Must be possible to add a posteriori to any other scope (e.g. EMF), see also compositional scopes
- VQ Engine owner shall be able to provide (through an easy API) the contents of custom relations that the query definitions can rely on
- Do we need surrogate values in the EMF base index?
- Rethink matcher API
- In case of surrogates, remove types from API
- Can Matches also be Tuples, or at least backed by them? Try to reduce (persistent and transient) duplication.
- Distributed processing extensions
- ???