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.
VIATRA/DeveloperDocumentation/Viatra2.0Brainstorming
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
- ???