Skip to main content
Jump to: navigation, search


Meeting minutes 2014. 01. 29.


Validator refactoring

according to discussions on yesterday’s in-the-flesh meeting, the relocation of pattern language validators should be considered for two reasons: A. move from EMFPatternLanguageJavaValidator to the core PatternLanguageJavaValidator if not EMF-specific, to enable versions of the current pattern language that query non-EMF models; B. push down from PLJV to PSystem sanity checking if possible, so that other pattern specification sources can benefit from the check as well. I have conducted a quick investigation, and summarize my findings below.

A. (14 checks in EMFPLJV)

  • It seems that two checks (“checkParametersNamed” and “checkForCartesianProduct”) can safely be moved from EMFPLJV to PLJV.
  • There are some checks that are definitely tied to the EMF-specific language, such as the concept and all complications of EPackage imports (3 checks), or well-behaving derived features (1 check).
  • In-between, there is a great number of checks that could be promoted to PLJV if some aspects of the type system are abstracted into virtual functions that EMFPLJV can then specialize according to Ecore:
    • The simplest case is the two “checkForWrongVariablesInXExpressions” checks, which only require distinction of structural classes from data types, and express a restriction that is valid (but not enforced) in the core pattern language – so they can be considered for PLJV.
    • Almost half of the checks (6), however, is about type checking. One wonders whether it’s really worth it to de-EMF-ify these checks.

B. (14 checks in PLJV)

  • Three of the checks (“checkReturnTypeOfCheckConstraints”, “checkForImpureJavaCallsInEvalExpressions”, “checkForImpureJavaCallsInCheckConstraints”) are XBase-specific, so they can’t be turned into PSystem sanity checks.
  • Three of the checks (“checkPrivatePatternUsage”, “checkPatterns”, “checkPackageDeclaration”) restrict the structure of a PatternModel object, and thus are not suitable for PSystem either – unless we want to mirror PatternModel in PSystem.
  • Three of the checks (“checkCompareConstraints”, “checkVariableNames”, “checkVariableUsageCounters”) might be more difficult to replicate with equivalne behaviour on PSystem due to the abstraction gap between the two representations. This question might require further investigation to settle.
  • It seems that the remaining 5 checks can be transcribed to PSystem. But then we need a mechanism to trace back a problem report referring to a PQuery/PAnnotation/PBody/PConstraint to an Eclipse problem marker attached to the corresponding Pattern/Annotation/PatternBody/Constraint.

Pattern registry

  • The Pattern Registry was not updated - if nothing comes up I would suggest removing it entirely, because:
  • The interesting features (e.g. dynamic group building) were not implemented because of lack of time
  • The base design was focused on managing different versions of the same patterns, and providing consistent views about it. As of now, it is much easier to provide these views via the SpecificationBuilder mechanism; so a revisit of the design seems necessary to me.
  • And practically no-one is using pattern registry (the only known use in a project can trivially be replaced with the QuerySpecificationRegistry)

Action plan

  • xtext vs incquery issue
    • TODO bugzilla: create issue to introduce a fourth type of matcher scope: resourceset with special filters (e.g. to filter out Java AST elements when an xtext grammar with xbase is to be used)
Release plan draft

Back to the top