[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] OCL delegate namespaces
|
Hi,
we should check what else may depend on o.e.o.ecore. Obviously, the
Impact Analyzer in its current implementation is specific to it and
would need adjustments to work with o.e.o.pivot. It may also be useful
to ensure that there are no major performance hits. In particular, I
hope we can make the latest changes we applied to the o.e.o.ecore
evaluator regarding the "inlined" use of the cached compiled delegate
expressions also available for the o.e.o.pivot implementation (if that
isn't already the case).
It may also be worthwhile understanding ramifications external to the
project's codebase. How much do we know about the use of delegates with
their specific URI and any dependencies of such clients on the
particular metamodel being used (Ecore, UML, Pivot)?
Has concrete syntax compatibility across Ecore and Pivot already been
analyzed? Can users assume that their expressions will flawlessly
compile when we redirect to Pivot, or how much adjustment will be required?
Best,
-- Axel
On 1/27/2011 6:42 PM, Ed Willink wrote:
Hi
While waiting for clues on OCL UML editor integration I'm looking at
making the OCL Console and generate Validate use the new pivot model
functionality.
This mainly requires redirecting the OCL delegates, so for API
compatibility Ecore files with
"http://www.eclipse.org/emf/2002/Ecore/OCL"; annotations feed OCL to the
old LPG parser and evaluator
"http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot"; annotations feed OCL
to the new Xtext parser and evaluator
This gives the API compatibility that we require for 3.1.0, although
"http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot"; does not include
"examples"; suggestions?
By placing all the new code in org.eclipse.ocl.examples.pivot etc we
avoid the Xtext 2.0 problem of changing API on an established namespace,
and certainly in 4.0 we only promote org.eclipse.ocl.examples.pivot to
org.eclipse.ocl.pivot. org.eclipse.ocl and org.eclipse.ocl.ecore can
remain for many releases if really necessary.
To the point:
In 4.0, do we redirect the delegates so that
"http://www.eclipse.org/emf/2002/Ecore/OCL";
accesses the new functionality, which should be compatible on the
external API?
If we don't, all "http://www.eclipse.org/emf/2002/Ecore/OCL"; must be
changed manually or by some new tool.
If we do, all "http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot"; can be
changed manually or by some new tool or by a compatibility support.
My preference is to redirect in 4.0 so that
"http://www.eclipse.org/emf/2002/Ecore/OCL/Pivot"; has limited liftetime.
Should we add "http://www.eclipse.org/emf/2002/Ecore/OCL/3.1"; so that
there is a delegate mapping that is more explicit?
Regards
Ed Willink
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
