Home » Modeling » OCL » 2 OCL-EMF Integration Questions
| 2 OCL-EMF Integration Questions [message #46357] |
Wed, 12 December 2007 03:19  |
Eclipse User |
|
|
|
Hi.
I have two questions:
1. Access to a field, if the getter is overwritten
We use OCL to define "derived" attributes, as in Christian Damus's
Example. These attributes have derive=true, volatile=true,
transient=true, changeable=false, and everything works well.
Now, in EMF I can have derived attributes with only derive=true,
but volatile=false, transient=false, changeable=false. In these
attributes a derived getter will typically read the field.
How is this possible in OCL? If the feature is called xyz, and
the getter is getXyz(), what happens if I want to use xyz in
the OCL derivation of getXyz()? Is xyz in ocl always translated into
the getter, or does it try to find the field, and only then the getter?
(follow up question: can I access EMF Operation getXyz2() as xyz2 in OCL??)
2. Access to the super version of an operation
We use OCL to define the "body" of operations, as in Christian Damus's
Example.
If such an operation overrides one from the super class, how can I call
in such an operation the super-version of the same operation?
Thanks a lot in advance for any hint.
Philipp Kutter
|
|
|
| Re: 2 OCL-EMF Integration Questions [message #46390 is a reply to message #46357] |
Wed, 12 December 2007 08:26  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Philipp,
See some replies in-line, below.
HTH,
Christian
Philipp W. Kutter wrote:
> Hi.
>
> I have two questions:
>
> 1. Access to a field, if the getter is overwritten
>
> We use OCL to define "derived" attributes, as in Christian Damus's
> Example. These attributes have derive=true, volatile=true,
> transient=true, changeable=false, and everything works well.
>
> Now, in EMF I can have derived attributes with only derive=true,
> but volatile=false, transient=false, changeable=false. In these
> attributes a derived getter will typically read the field.
Does this really work? I would expect this to confuse some parts of the EMF
run-time, that would expect a derived property to be unchangeable. I know
that some corners of the GMF run-time make this assumption.
> How is this possible in OCL? If the feature is called xyz, and
> the getter is getXyz(), what happens if I want to use xyz in
> the OCL derivation of getXyz()? Is xyz in ocl always translated into
> the getter, or does it try to find the field, and only then the getter?
The EcoreEvaluationEnvironment in MDT OCL uses EMF's reflective eGet() API
to obtain a property's value. EMF will usually generate an eGet() that
calls the accessor method. Java reflection is only used to invoke
operations, as EMF provides no eCall(EOperation, EList<?>) API.
> (follow up question: can I access EMF Operation getXyz2() as xyz2 in
> OCL??)
If the Ecore model actually defines a getXyz2() operation, then OCL will
have access to it. If it is only the accessor method for a property, then
OCL won't see it because it is simply a Java implementation pattern.
> 2. Access to the super version of an operation
>
> We use OCL to define the "body" of operations, as in Christian Damus's
> Example.
>
> If such an operation overrides one from the super class, how can I call
> in such an operation the super-version of the same operation?
If your OCL expression has a variable b of type B which specializes A, and B
redefines an operation foo() and a property x from A, then you can invoke
these features of A by casting:
b.oclAsType(A).foo()
b.oclAsType(A).x
However, MDT OCL does not support this usage. Indeed, as it is specified by
OMG, it would be a little difficult to implement and has semantics
inconsistent with variable initialization, anyway. Consider that, using
the above example, if the following indicates that we want to access A's
definition of foo()
b.oclAsType(A).foo()
then what does the following mean?
let bAsA : A = b.oclAsType(A) in
bAsA.foo()
Should this invoke A::foo() or B::foo()? I would expect the latter, for
consistency with the following in which A additionally has a
self-association A::relatedAs:
a.relatedAs->collect(rel : A | rel.foo())
In this case, one clearly expects that for any Bs in the collection of
relatedAs, we would get B::foo() despite the fact that the rel variable's
static type is A.
> Thanks a lot in advance for any hint.
>
> Philipp Kutter
|
|
|
| Re: 2 OCL-EMF Integration Questions [message #46537 is a reply to message #46390] |
Wed, 12 December 2007 15:50 |
| Eclipse User |
|
|
|
Hi, Christian.
Comments inline
>> 1. Access to a field, if the getter is overwritten
>>
>> We use OCL to define "derived" attributes, as in Christian Damus's
>> Example. These attributes have derive=true, volatile=true,
>> transient=true, changeable=false, and everything works well.
>>
>> Now, in EMF I can have derived attributes with only derive=true,
>> but volatile=false, transient=false, changeable=false. In these
>> attributes a derived getter will typically read the field.
>
> Does this really work? I would expect this to confuse some parts of the EMF
> run-time, that would expect a derived property to be unchangeable. I know
> that some corners of the GMF run-time make this assumption.
I asked the question on the emf group.
>
>
>> How is this possible in OCL? If the feature is called xyz, and
>> the getter is getXyz(), what happens if I want to use xyz in
>> the OCL derivation of getXyz()? Is xyz in ocl always translated into
>> the getter, or does it try to find the field, and only then the getter?
>
> The EcoreEvaluationEnvironment in MDT OCL uses EMF's reflective eGet() API
> to obtain a property's value. EMF will usually generate an eGet() that
> calls the accessor method.
Ok, thus there is no way to get to the property, if not through the getter.
> Java reflection is only used to invoke
> operations, as EMF provides no eCall(EOperation, EList<?>) API.
I know. I tried to get Ed on the topic again. All I found out, is that
he would call it eInvoke. For the signature, I think it would be
something like
eInvoke(EOperation, EList<EArgument>
where EArgument would be a wrapper for actual values for ETypes (in many
and non-many versions of course). We will try to find time to work on this.
>
>
>> (follow up question: can I access EMF Operation getXyz2() as xyz2 in
>> OCL??)
>
> If the Ecore model actually defines a getXyz2() operation, then OCL will
> have access to it. If it is only the accessor method for a property, then
> OCL won't see it because it is simply a Java implementation pattern.
I understand. You always go over eGet() for the features, and you only
add those operations to the OCL environment, which are declared in the
EClass.
>> 2. Access to the super version of an operation
>>
>> We use OCL to define the "body" of operations, as in Christian Damus's
>> Example.
>>
>> If such an operation overrides one from the super class, how can I call
>> in such an operation the super-version of the same operation?
>
> If your OCL expression has a variable b of type B which specializes A, and B
> redefines an operation foo() and a property x from A, then you can invoke
> these features of A by casting:
>
> b.oclAsType(A).foo()
>
> b.oclAsType(A).x
>
> However, MDT OCL does not support this usage. Indeed, as it is specified by
> OMG, it would be a little difficult to implement and has semantics
> inconsistent with variable initialization, anyway. Consider that, using
> the above example, if the following indicates that we want to access A's
> definition of foo()
>
> b.oclAsType(A).foo()
>
> then what does the following mean?
>
> let bAsA : A = b.oclAsType(A) in
> bAsA.foo()
>
> Should this invoke A::foo() or B::foo()? I would expect the latter, for
> consistency with the following in which A additionally has a
> self-association A::relatedAs:
>
> a.relatedAs->collect(rel : A | rel.foo())
>
> In this case, one clearly expects that for any Bs in the collection of
> relatedAs, we would get B::foo() despite the fact that the rel variable's
> static type is A.
This I will send for feedback to Mariano Belaunde, the OCL chair. He is
as well in my LinkedIn network, please let me know if you are interested
to connect with him. By the way, it would be great, if we would see an
integration of their OCL implementation with the MDT OCL implementation,
similar to the way how TopcaseD is integrating with MDT.
Best, Philipp
>
>
>
>> Thanks a lot in advance for any hint.
>>
>> Philipp Kutter
>
|
|
|
| Re: 2 OCL-EMF Integration Questions [message #46810 is a reply to message #46390] |
Thu, 13 December 2007 15:39 |
| Eclipse User |
|
|
|
Eds comments regarding the first question:
-------- Original Message --------
Subject: Re: derived features with volatile=false, transient=false,
changeable=true
Date: Wed, 12 Dec 2007 18:04:12 -0500
From: Ed Merks <merks@ca.ibm.com>
Organization: EclipseCorner
Newsgroups: eclipse.tools.emf
References: <fjpg9i$jfn$1@build.eclipse.org>
Philipp,
Comments below.
Philipp W. Kutter wrote:
> Hi.
> Are such features working?
Where you define working how?
>
> I asked on the OCL group, and someone asked, whether such a feature
> would work.
>
> I do not see any problem for such a feature. Is there one?
You need to write the code for the methods.
>
> Best, Philipp
>
> > 1. Access to a field, if the getter is overwritten
> > >
> > > We use OCL to define "derived" attributes, as in Christian Damus's
> > > Example. These attributes have derive=true, volatile=true,
> > > transient=true, changeable=false, and everything works well.
> > >
> > > Now, in EMF I can have derived attributes with only derive=true,
> > > but volatile=false, transient=false, changeable=false. In these
> > > attributes a derived getter will typically read the field.
>
> Does this really work? I would expect this to confuse some parts of
> the EMF
> run-time, that would expect a derived property to be unchangeable. I
> know
> that some corners of the GMF run-time make this assumption.
It's assumed that derived properties are computed from other values, so
they aren't copied, but as part of being computed they could be set and
hence produce notification...
|
|
|
Goto Forum:
Current Time: Thu Oct 30 22:56:33 EDT 2025
Powered by FUDForum. Page generated in 0.05051 seconds |
Home