[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[mdt-ocl.dev] 3.0.1 Plans
|
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