Re: [mdt-ocl.dev] 3.0.1 Plans

[Kenn Hussey <kenn.hussey@xxxxxxxxx>]

Hmm. You can't add new functionality in a maintenance release. Although the OCL to Java generator does sounds really useful/desirable.

Note that OCL can have major and minor releases as often as it likes, possible out of sync with the official release train. Why not add this new functionality in HEAD as part of a new release that ships when you want it to?

Kenn

On Tue, Jun 1, 2010 at 2:26 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

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

_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev