[mdt-ocl.dev] 3.0.1 Plans

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

[Kenn: You might have to -1 the proposal below.]

While writing the OCLinEcore tutorial, I have been pleased by how much 
fits together, and fixed one trivial drop-off; we needed a Create 
Dynamic Instance within the text editor.

There are two major problems and one annoyance from a usage perspective.

a) Bug 315034; a loaded model is not valid after its meta-model is 
changed (not even if the change was just a debugged invariant). This 
gives major pain (NPE, CCE, IAE and worse) in the OCL Interpreter and 
Sample Reflective Ecore Editor Properties View. We need to contribute a 
meta-model reloader to EMF (a proxy resolver for all eClass references).

b) The editor has no Well-Formedness Validation. So any simple 
collection type errors go undetected and just give a mysterious nothing 
or OclInvalid in the console.

c) There is no mechanism to load a CompleteOCL document into the OCL 
Interpreter.

a) and c) are simple isolated developments

b) sensibly drops out as part of the progression to a clean reflective 
pivot model supporting the model-driven standard library.

I don't want users to have to wait a year for editor validation. How can 
this be done in a maintenance release?

Well-formedness constraints are (or should be) cut-and-paste equivalent 
to the OCL specification. We now have the technology to integrate these 
in our models, so there is no need for custom Java, except that 
instinctively, I cannot contemplate running interpreted OCL queries 
during compilation of big meta-models.

----

Proposal; rather than doing Java generation one day, let's do it now and 
use it ourselves.

Step 1: Develop an OCL to equivalent Java code generator - very little 
optimisation, BigInteger, BigDecimal throughout but inline Java rather 
than deep interpreter call trees.

Step 2: Enrich our meta-models with this OCL-derived Java.

Step 3: Use the enriched pivot models to provide validation in the editor.

----

Practicalities; in order to ship this in 3.0.1

-- I continue to do everything in the examples plugins. Only maintenance 
changes to non examples.

-- At about M4, we graduate the examples plugins to non-examples after a 
significant review by all committers. CVS HEAD changes from 3.0.1 to 4.0.0.

-- During M4-M6 we migrate the LPG parser and analyzer to align with the 
Xtext and ANTLr tooling recognising QVTo as our API compatibility 
referee. Long term I think we need a major rethink of the LPG Analyzer 
'protected' API, but we need to make the Xtext/Library/Generation 
facilities so much better in 4.0.0 that QVTo changes from choice and 
with assistance rather than compulsion in Indigo+1.

----

One day, perhaps gradually, we add optimisation to the Java generation.

    Regards

        Ed Willink