|
Re: OCLinEcore issues with derived attributes/operations [message #555458 is a reply to message #555335] |
Thu, 26 August 2010 16:26 |
Ed Willink Messages: 7655 Registered: July 2009 |
Senior Member |
|
|
Hi Joern
For OMG OCL, there is no obvious difference between an individual
attribute or parameter-less operation; it's just a matter of style.
However once OCL defines the semantics of overloading and dynamic
resolution it is likely that an overloaded attribute will be an error
and an overloaded operation a dynamic dispatch (just like Java).
For EMF and MDT/OCL features use setting-delegate registrations while
operations use invocation-delegates; these could be very different, but
only if you like to make things deliberately confusing; all three
delegates should be registered in unison. The setting delegates use
reflection through the longstanding eGet(). The invocation delegates use
eInvoke() introduced in 3.6M4. If you neglect to set Operation
Reflection true in genmodel, eInvoke() is not generated; MDT/OCL 3.0.1
will give a warning and workaround this misconfiguration.
Please submit a Bugzilla for the NPE with a hopefully very small
demonstration project (unless its the Operation Reflection feature),
Regards
Ed Willink
On 26/08/2010 12:26, Joern wrote:
> I am trying to enhance an Ecore model with several constraints. What is
> the technical difference in the implementation using OCL operations and
> derived, volatile attributes? In fact the same OCL expression given in a
> operation does work but not for a derived, volatile attribute (it
> results in one NPE per element using the reflective ecore editor). An
> example to derive the opposite reference to self:
> attribute derivedOpposite: OtherType { derived,volatile }
> {
> derivation:
> OtherType.allInstances()->select(reference=self)->asSequence()- >first();
> }
> Or does this difference roots in other invariants using this
> attributes/operations?
> Thanks in advance,
> Joern
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03515 seconds