[news.eclipse.modeling.mdt] Re: Derive constraints

["Kenn Hussey" <Kenn.Hussey@xxxxxxxxxxxxxxx>]

Christian,

I'm not sure that defining an operation to describe the mechanism by which a 
value is derived is necessarily a Java-ism. This convention of using (OCL) 
operations to describe how properties are derived was used in the UML 
metamodel/specification long before the Java implementation was provided at 
Eclipse. I agree that it's awkward (like many things in UML). We're actually 
looking at formalizing the way types and proeperties can be derived based on 
other types/properties as part of the IMM specification submission at the 
OMG...

In the meantime, could the visibility of the operation not be used to 
restrict its exposure via OCL? For example, I usually make all of my 
"implementation" operations protected...

Kenn

"Christian W. Damus" <cdamus@xxxxxxxxxx> wrote in message 
news:ftilrb$k85$1@xxxxxxxxxxxxxxxxxxxx
> Hi, Kenn,
>
> This has the unhappy side-effect of actually *modeling* the accessor
> operation, which is a Java-ism.  This accessor then becomes available to
> OCL, resulting in possible confusion and even incompatibility of OCL
> expressions with other implementations of the metamodel that don't model
> these accessors.
>
> Is it possible that the code generation could elide the accessor operation
> from the Ecore representation that results?  This, together with the
> ability to use package-merge to include the accessors only for codegen but
> not the *.metamodel.uml resource, would make a clean metamodel for clients
> such as OCL.
>
> Cheers,
>
> Christian
>
>
> Kenn Hussey wrote:
>
>> Javi,
>>
>> Yes, the current way to do it (as supported by the UML2 code generator) 
>> is
>> to introduce an operation that has the same signature as the accessor you
>> are looking to derive. Ed's also looking at how to provide built-in
>> support for feature derivation in EMF - take a look at
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701.
>>
>>
>> Kenn
>
> -----8<-----