I just wanted to share some thoughts about the Eclipse Modelling Project and it's possible future.
There are different projects offering different languages in order to work on EMF models. We have JET, OCL, ATL, MOFScript, Xpand, Xtend, Check, etc...
All of them have one thing in common, they need access to the model (based on it's metamodel)
The OMG proposes EssentialOCL in order to query EMOF models.
So should we directly implement it (as it's already done in EMFT)? Or should we create a improved "pragmatic implementation tailored to EMF" as Ecore is a pragmatic interpretation of EMOF (actually I think EMOF is a standardization of Ecore, but anyway...)?
I think we should implement a pragmatic EOCL, where the typesystem is Ecore not EMOF. Additionally we could improve the language features (e.g. a proven proposal for OCL 3.0).
Some examples:
- OCL has no support for full fledged generics. The typeparameters for Collections and Tuples are hard coded.
- OCL has no support for closures. The higher-order functions are first class citizens (hard coded).
- OCL has no polymorphism (as far as i could see, I think the spec is not very clear with this)
- OCL has some strange concepts (the strange Association navigation, for instance)
We could create an EssentialOCL 3.0 which is mainly syntax compatible to OCL 2.0, but much more powerful, with features like type inference, closures, full fledged generics, dynamic extensions and stuff.
Have a look at the C#3.0 features. It's not that hard to implement such an expression language!
Based on such an OCL 3.0 runtime we could create a validation language, one or two transformation languages and a model2text template language, everything well integrated and interoperable.
Additionally we might want to describe metamodels (including behaviour) in a textual manner.
Why should the EMP be 100% OMG standard compatible if it is not the best solution we could think of? Hey, it's Eclipse, EMP don't need such an off-trade just for being standard compliant of course one shouldn't reinvent the wheel but if there are clear arguments against a standard, it should be improved. Additionally the standards of the OMG are not very widespread and practice proven.
Anyway, openArchitectureWare 4 has proved that the most important and helpful thing for developing generators is the integration and creation of a good language family, based on the same type system and the same expression language.
If anybody wants to bring the os community in such a direction, please, hire me so we can create the best MDSD tool chain on earth...
:-)
