-----Original Message-----
From: mdt-ocl.dev-bounces@xxxxxxxxxxx
[mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Axel Uhl
Sent: 03 February 2011 15:31
To: MDT OCL mailing list
Subject: Re: [mdt-ocl.dev] OCL delegate namespaces
Ok, well, let's just see how it turns out. I've been checking out the
examples.pivot bundle today and took a quick look. I can't
seem to find
any test cases, doc or other material explaining how to use it in
conjunction with an Ecore model. Any pointers you can provide?
Best,
-- Axel
On 2/3/2011 1:56 PM, Willink, Ed wrote:
Hi Axel
Just found thios on my work email; did'nt arrive at home.. strange.
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).
I'm not pushing for total migration until I have used it a
bit more and
the notional UML-alignment becomes more pedantic.
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)?
Nobody is yet using Pivot. UML is distinctly limited,
although in migrating
the OCL Console, it appears to have full control for UML;
I've just never
seen it
work.
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?
Both old and new parsers aspire to 100% grammar compliance
although the OMG
specification has made greater than 99% unachieveable
objectively. The old
parser had a lax-null option to deviate from the letter of the 2.0
specification.
It turns out that lax-null is much closer to the OCL 2.3
clarification of
null
and invalid.
The old parser is unlikely to change very much. The new
parser will converge
on OMG as OMG gets clearer.
In principle, most things will just work. Of course
anything involving eXXX
was broken in Helios M4. The Pivot Model should support
container(), which I
really must implement.
It should be possible to retrofit the old parser semantics
onto the Pivot
model
by defining an MDT-OCL-1.3.0.oclstdlib. Not high up my priorities at
present.
Regards
Ed Willink
Please consider the environment before printing a hard copy of this
e-mail.
The information contained in this e-mail is confidential.
It is intended
only for the stated addressee(s) and access to it by any
other person is
unauthorised. If you are not an addressee, you must not
disclose, copy,
circulate or in any other way use or rely on the
information contained in
this e-mail. Such unauthorised use may be unlawful. If you
have received
this e-mail in error, please inform us immediately on +44
(0)118 986 8601
and delete it and all copies from your system.
Thales Research and Technology (UK) Limited. A company registered in
England and Wales. Registered Office: 2 Dashwood Lang Road,
The Bourne
Business Park, Addlestone, Weybridge, Surrey KT15 2NX.
Registered Number:
774298
Thales UK Limited. A company registered in England and
Wales. Registered
Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone,
Weybridge, Surrey KT15 2NX. Registered Number: 868273
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
