| [incquery-dev] A muster of pattern language validators |
|
Hi all,
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.
I hope this helps in making future decisions about the existing
validators.
Cheers,
Gábor |